Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

23章継続的インテグレーション

Rachel Tannenbaum 著

Lisa Carey 編

　継続的インテグレーション（Continuous Integration）、あるいはCIは、「チームのメンバーが作業分を頻繁に統合するソフトウェア開発のプラクティスであり（中略）各インテグレーションは、できるだけ迅速にインテグレーションのエラーを検出するために、自動ビルド（テストを含む）により検証される」ようなものとして一般に定義される†1。簡単に言うと、CIの根本的なゴールは、問題のあるコード変更をできるだけ早期に、自動的に捕捉することである。

†1　https://www.martinfowler.com/articles/continuousIntegration.html

　実践上は、「作業分を頻繁に統合する」とは、モダンな分散アプリケーションにとって何を意味するのか。今日のシステムには、リポジトリー内の最新バージョンのコードのみならず、たくさんの変動する要素がある。事実、マイクロサービスへと向かう最近のトレンドでは、アプリケーションを破綻させるコード変更は、そのアプリケーションのプロジェクトがある直接のコードベース内に存在している見込みは低く、ネットワーク経由の呼び出しの反対側にある疎結合したマイクロサービス内にある見込みの方が高い。伝統的な継続的ビルドがバイナリ内の変更をテストする一方で、そのような継続的ビルドを拡張したものは、上流のマイクロサービスへの変更をテストするかもしれない。依存関係が、自身のアプリケーション内の関数呼び出しスタックから、HTTPリクエストやリモート関数呼び出し（RPC）へと移っているだけのことだ。

　コードの依存関係からさらにもっと進んだ先では、アプリケーションが定期的にデータを摂取したり機械学習モデルを更新したりするかもしれない。アプリケーションは、発展を続けるオペレーティングシステム、ランタイム、クラウドホスティングサービス、デバイス等の上で実行されているかもしれない。アプリケーションは、発展するプラットフォームの上に載っている機能であったり、あるいは発展を続ける基本機能を収容しなければならないプラットフォームであったりするかもしれない。これら全てのものが依存関係とみなされるべきであり、これらの変更を「継続的に統合する」ことも目指すべきだ。物事をさらに複雑にしているのは、これらの変化する構成要素は往々にして、チームや組織や企業の外部にいる開発者たちがオーナーとなっており、オーナーである外部の開発者たち自身のスケジュールに基づいてデプロイされていることだ。 ...