build serverとは? pipelineの背後にある頭脳

build serverは、pipelineをスケジュールし、jobをエージェントに割り当て、結果を保存し、ステータスをチームに提示する中心的なシステムです。

すべてのpipelineの背後には、コーディネーターがいます。build server (CI serverと呼ばれることもあります) がその頭脳です。eventを監視し、どのpipelineを実行するか判断し、jobをエージェントに配り、結果とログを収集し、全員にステータスを示します。serverは通常jobのstepそのものは実行しません。それはエージェントの役割です。serverは調整します。

build serverがすること

eventとtriggerをリッスンする。
pipeline runとそのjobをスケジュールする。
利用可能なエージェントにjobをディスパッチする。
ログ、結果、artifactを保存する。
dashboard、badge、通知を提供する。

server vs エージェント

serverは調整し、エージェントが実行します。1つのserverが多数のエージェントを管理します。この分離により、実行 (エージェントの追加) を調整 (server) とは独立にスケールできます。これが大規模なCIシステムが数千のjobを扱う方法です。

簡単な例

コードをpushすると、build serverがeventを受け取り、runを作成し、そのjobをアイドル状態のエージェントに割り当てます。エージェントがログと結果をストリームで返すと、serverはUIに表示されるrunのステータスを更新します。

セルフホスト vs マネージド

自分のbuild serverを運用する (Jenkinsが定番の例) こともできますし、マネージドのもの (GitHub Actions、GitLab CI) を使うこともできます。セルフホストは制御と保守の負担を与え、マネージドは保守をプロバイダーに肩代わりさせます。

server、エージェント、そして速度

serverは素早くスケジュールしますが、スループットは利用可能なエージェントに依存します。有能なserverもエージェントが不足すれば作業をキューに溜めます。マネージドrunner (Latchkey) はエージェントのキャパシティを提供するため、serverのスケジュールがキューではなく実際の並列実行になります。

重要なポイント

build serverはpipelineをスケジュールしエージェントを調整しますが、stepは実行しません。
serverは調整し、エージェントが実行します。1つのserverが多数のエージェントを動かします。
スループットは、serverのスケジューリングだけでなく、エージェントのキャパシティに依存します。