継続的インテグレーションとは?

著者 Kaveh Alemi·Latchkey

継続的インテグレーションとは、コードを共有ブランチに頻繁にマージし、各マージを自動のbuildとテスト実行で検証する実践です。

継続的インテグレーション、すなわちCIは、ある苦痛な問題を解決するために生まれました。開発者が何週間も孤立して作業し、その後マージしようとすると、コンフリクトや予期せぬ問題が積み重なって"インテグレーション地獄"になるという問題です。CIはそれを、小さく検証された多数のマージに置き換えます。

中心となる考え方

変更を長命なブランチに溜め込む代わりに、各開発者が自分の作業を頻繁に、理想的には1日に数回、メインラインに統合します。すべての統合が自動的にbuildとテストにかけられるため、問題は他の全員の最新版に対して即座に表面化します。

実際の仕組み

• 開発者が小さな変更を頻繁にcommitします。
• CI serverがリポジトリを監視して新しいcommitを探します。
• 変更のたびにコードをbuildし、テストスイートを実行します。
• 結果は報告され、多くの場合pull requestのステータスチェックとして表示されます。
• 壊れたbuildは、素早く修正すべきストップ・ザ・ラインのイベントとして扱われます。

実例

2人の開発者が同じサービスに機能を追加しています。それぞれがpull requestを開き、CIが両方をbuildしてテストします。片方のPRのテストが、もう片方の変更との相互作用で失敗します。統合が早く頻繁に行われていたため、コンフリクトは小さく明白で、数週間後のストレスの多いreleaseの週末に発見されるのではなく、数分で修正されます。

なぜ重要か

CIはバグを書いてからそれに気づくまでのフィードバックループを短縮します。変更と検証の間の隔たりが小さいほど、修正は安くなります。作者がまだ文脈を頭の中に鮮明に持っているからです。またmainブランチを、全員がその上に構築できる既知の良好な状態に保ちます。

CIを機能させる実践

• buildを速く保ち、人々が頻繁に実行できるようにします。
• 壊れたmainブランチは、他の何よりも先に修正します。
• 緑のbuildを信頼できるだけの十分な自動テストを書きます。
• 週単位ではなく、少なくとも毎日統合します。

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とは、頻繁にマージし、各マージを自動的に検証することを意味します。
• 変更を小さく保つことで"インテグレーション地獄"を防ぎます。
• 速いbuildと緑のmainブランチが、それを機能させる要です。

よくある質問

関連ガイド