CI serverとは?
CI serverとは、リポジトリを監視し、変更時にpipelineを起動し、コードをbuildしてテストするマシンを調整するシステムです。
CI serverは継続的インテグレーションのオーケストレーターです。コードの変更を待ち受け、どの作業を実行するかを決め、その作業をrunnerに割り当て、結果を集めます。一連のスクリプトを、自動化され観測可能な処理へと変えます。
何をするか
CI serverはpushやpull requestなどのイベントを検出し、リポジトリのpipeline定義を探し、結果として生じるjobをスケジュールします。それらのjobを実行マシン (runner) に引き渡し、進捗を追跡し、ログと結果を集約し、多くの場合pull requestのチェックとして開発者にステータスを報告します。
サーバー対runner
2つの役割を分けて考える価値があります。CI serverはスケジュールし調整する頭脳であり、runnerは実際にbuildとテストを実行する筋肉です。1つのサーバーは通常、多数のrunnerに作業を割り当て、jobを並列で実行できるようにします。GitHub Actionsでは、GitHubがホストするサービスがサーバーであり、runnerが作業を行います。
実例
開発者がpull requestを開きます。CI serverはイベントを見て、workflowファイルを読み、変更をbuildしてテストするjobをキューに入れます。利用可能なrunnerにjobを割り当て、ログをストリームで返し、runnerが終わるとPRのチェックを緑または赤にします。
なぜ中心的なのか
CI serverは、コードの変更を自動検証に結びつける唯一の点です。それがなければ、buildとテストは手動で、一貫性なく実行されるでしょう。それがあれば、すべての変更が同じ方法で自動的に、目に見える結果とともに検証されます。その信頼性とrunnerの速度が、CIがどれほど快適に感じられるかを直接形作ります。
ホスト型runner対セルフマネージドrunner
多くのCIサービスは、マシンを管理せずに済むホスト型runnerを提供していますが、それらは規模が大きくなると遅かったりコストがかかったりします。Latchkeyのようなマネージドrunnerプラットフォームは、同じCI serverに接続する、より速く信頼できるrunnerを提供し、開発者が最も感じるシステムの部分を改善します。
Applying this to your pipeline
- Measure before changing. Most CI optimisation targets the wrong step because the slow one is assumed rather than timed.
- Cache what is expensive to produce and cheap to validate, and key the cache to the exact tool version.
- Fail fast: run the cheapest checks that can reject a change first, so an expensive job never starts on code that cannot pass.
- Prefer determinism over speed when they conflict. A fast pipeline nobody trusts gets re-run, which is slower than a slow one that is believed.
重要なポイント
- CI serverはpipelineを起動し、作業を調整します。
- サーバーはスケジューリングし、runnerが実際のbuildとテストを実行します。
- その信頼性とrunnerの速度がCI体験を決定づけます。