継続的インテグレーションがなぜ重要なのか

継続的インテグレーション（CI, Continuous Integration）が大事というのはよく聞く話だが、幸運にもそれはあって当たり前のものだったのでなぜ重要なのかが納得できていなかった。『レガシーコードからの脱却』で初めてその理由が腹落ちしたので、ここに書いておく。

継続的インテグレーションのあるとき/ないとき

継続的インテグレーションとは、リリース直前まで待つのではなく、ソフトウェアをビルドしながら統合することだ。（p. 105）

ということは…

継続的インテグレーションのない状態
=> 本番リリース直前に初めてビルド・統合される。つまり、リリース時に初めてコンパイルエラーやバグが発覚する

継続的インテグレーションのある状態
=> コードに変更を加えるたびに全体のビルド・統合を行う。つまり、リリースのずっと前にコンパイルエラーやバグに気づける。また、変更の規模が少ないので原因を突き止めるのも容易。

ビルド専用のビルドサーバーを用意し、リポジトリに新しいコードが追加されたらシステム全体をリビルドする。そして自動テストを実行して結果を知る。

このサイクルを自動で回し続けることで、リリース直前にエラーやコンフリクトに直面することを避けられる。

継続的インテグレーションには以下のメリットがある。

小さい変更に対してフィードバックが得られるので、修正が容易
- (リリース直前に問題が発覚してしまうと、緊急に対処しなければならないにもかかわらず範囲が大きく修正コストがかかる)

さきほど「あって当たり前のものだった」と書いたが、そういえば入社1年目に自分ひとりで書いた小さなリポジトリにはCIツールが入っていない。ついでに言うとテストも無い🙃（ちなみに最初のリリース以来更新は入っていない。ほぼ触らないプロダクト）

困っていること、そしてチーム開発になったら困るであろうことを書いてみる。

開発/本番環境に入れてみるまで、壊れていることに気づけない（手元で簡単な動作確認はできるが、カバレッジが低い）
チーム開発になった場合（仮定）
- masterが更新されるたびに取り込む必要があり、取り込み作業に加えてコンフリクト修正の手間もかかる
- masterを取り込むたびに手動で動作確認をする必要がある
- masterへのマージが相次いだ場合は、壊れていることが確認できないまま or 十分な動作確認ができないまま本番にリリースされてしまう可能性がある
- masterへのマージが相次いだあとに壊れた場合、原因の切り分けが難しい

やばすぎ💥💥💥

本を読んだあとに改めて考えてみると、継続的インテグレーションがなぜ重要なのかが納得できた。