「CI は入れています」と言いながら、実態はプルリクエストでテストが走るだけ、という現場は珍しくありません。
継続的インテグレーションという言葉が指しているのは、ツールではなく統合のやり方そのもの。
DevOps を学び直している立場で定義から追いかけると、CI が要求しているのは思ったより厳しい条件でした。
その中身を、提唱者の解説に沿って整理します。
CI の定義は「毎日メインラインへ統合する」
Martin Fowler 氏の解説では、CI はチームの各メンバーが自分の変更を同僚の変更とともに少なくとも毎日コードベースへマージし、その統合を自動ビルドで検証する進め方。
ポイントは頻度のほうにあり、同じ記事には「どのコードも数時間を超えて未統合のままにしない」という言い方も出てきます。
なぜそこまで急ぐのか。
統合を遅らせるほど、他人の変更との差は静かに広がっていくからです。
差が小さいうちなら衝突は数分で片づき、大きくなってから初めて気づくと数日かかる。
CI が縮めようとしているのは、この「壊れてから気づくまでの時間」になります。
成立条件は「単一のメインライン」と「自己テストビルド」
ひとつ目の条件が、製品の現在の姿を表す共有のメインラインを1本だけ持つことです。
全員がそこへ統合するので、長生きするフィーチャーブランチに閉じこもると前提が崩れる。
ふたつ目が自己テストビルドで、ビルドに自動テストが組み込まれている状態を指します。
同じ記事は「テストがグリーンなら、製品に重大なバグは無い」と言えるところまで作る、という水準を置いていました。
テストが無い自動ビルドは、コンパイルが通ったことしか教えてくれません。
みっつ目が速さで、コミットビルドはおおむね10分程度を目安に収めるよう書かれています。
1日に何度も回す仕組みなので、遅いビルドは統合の頻度そのものを下げてしまう。
テストを並列に流す、重いテストは後段へ回す、といった工夫もこの目安から逆算して決められます。
Continuous Integration（Martin Fowler）
壊れたビルドを最優先で直す
CI で運用ルールとしていちばん効くのが、統合ビルドが失敗したらその修正を最優先に置くという約束です。
同じ記事では、通常の解決策は問題のコミットをすぐ revert することだと説明されています。
原因を追いかけるのは、メインラインをグリーンに戻してからでよい。
revert は敗北ではなく通常運転として扱う、と先に決めておくと判断が速くなるはず。
赤いまま放置すると、次に統合する人は自分の変更が壊したのかどうかを判断できなくなります。
そうなると全員がビルド結果を見なくなり、仕組みだけが残って安全網としては死ぬ状態に落ちてしまう。
壊れたビルドを直す速さは、そのままチームが CI をどれだけ信じているかの指標にもなる。
「CIツールを入れた」は CI ではない
ここがいちばん誤解されやすいところです。
フィーチャーブランチ上で CI サービスを走らせているだけの状態を、同じ記事は半統合（semi-integration）と呼んで区別しています。
理由もはっきり書かれていて、開発者が自分の作業をメインラインへ押し戻さなければ、他のメンバーはその作業を見られないから。
ブランチを切ること自体が問題なのではなく、そこに数日こもる運用が CI の前提を外してしまう、という話。
つまり CI の本体は、ツールではなく統合の頻度と、統合先が1本であることにあります。
自分の小さな仕組みでも、公開前に自動チェックを通す形にしておくと感覚はつかみやすい。
最後に
CI の要件は、メインライン1本・毎日以上の統合・自己テストビルド・10分のビルド・壊れたら即修正、という並びで整理できます。
このうち技術で解けるのは後半だけで、前半はチームの約束事。
ツールを入れる前にブランチをどこまで短命にできるかを決めるほうが、効果は大きいはずです。
そのうえで「どの粒度のテストをどれだけ持つか」を決めるなら、テスト戦略の記事が下敷きになります。
統合したものをいつでも本番へ出せる状態に保つ次の段階は、継続的デリバリー（CD）の記事で整理しました。
DevOps の全体像から追いたい方は、開発と運用の壁がなぜ生まれるかをまとめた記事も参考になると思います。
以上です。
コメントを残す