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

継続的インテグレーションとは、コードを共有ブランチに頻繁にマージし、各マージを自動の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を信頼できるだけの十分な自動テストを書きます。
週単位ではなく、少なくとも毎日統合します。

重要なポイント

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