デバッグ・サイクルを高速に回してコード品質を改善する（1） ―― 「繰り返しビルド＆テスト」に必要な環境とは

継続的インテグレーション（Continous Integration：CI，常時結合とも呼ばれる）とは，ソフトウェア開発において，ソース・コードに変更を加えるたびにビルドとテストを行い，常に動くソフトウェアがある状態を保つという手法である．継続的インテグレーションは，XP（Extreme Programming）のプラクティス（実践項目）の一つとして知られている．この手法を継続的に実践するためには，ビルドやテストにかかる時間が短いこと（できれば自動化）が望ましい．また，継続的インテグレーションを実施するためのツールが，商用とフリーの両方で出されている．本連載では，継続的インテグレーションとは何かについて解説し，実施するために必要な考え方やツールについて解説する．（編集部）

　継続的インテグレーション（Continous Integration：CI）は，ソース・コードに変更を加えるたびにビルドとテストを行うという手法であり，Kent Beckらが提唱しているXP（Extreme Programming）のプラクティス（実践項目）の一つとして知られています．この手法を導入することにより，以下のような効果が上がることが期待できます．

• 不具合を修正した際に，バイナリへの反映を速くできる
• ビルドを頻繁に行うことにより，ビルド・エラーをたたき出せる
• 常に「動く」バイナリがあるため，テストの際に「動かない」といったリスクを減らすことができる

　しかし，ビルドやテストにたいへんな手間がかかるようでは，繰り返しビルドとテストを行うこの手法を導入するのは難しいでしょう．継続的インテグレーションを実現するためには，ソース・コードのコミットを契機にして，自動的にビルドと（自動化された）テストを行うことができる環境を構築する必要があります．幸いにも，継続的インテグレーションを実現するためのツールが，商用とフリーの両方で出されています．ここでは，継続的インテグレーションについて解説し，実施に必要な機能などについて紹介します．

●継続的インテグレーションってどんなもの？

　「継続的インテグレーション」と言われても，具体的なイメージがわきにくいかもしれません．そこで，実際の運用はどのようなものなのかを，以下に紹介します．

（パターン1）チェックイン/コミットを契機にビルドとテストを実行する

　通常，継続的インテグレーションは，構成管理ツールと連携した形で実施します（図1）．構成管理ツールで管理しているすべての変更に対して，ビルドとテストを実施します．すべての開発者が同じ条件でビルドとテストを実施するため，（自動化されたテストでチェックできている範囲での）品質を保つことが可能です．

図1　チェックイン/コミットがあれば自動でビルドする（パターン1）

　先にチェックイン/コミットが行われ，それを受けてビルドを実施するので，もしビルドあるいはテストが失敗した場合には、その変更を取り消す（ロールバック）か，または再修正することになります．履歴を残すためには，ロールバックよりも再修正や再登録が望ましいでしょう．

（パターン2）チェックインの前にビルドとテストを行い，合格したものをチェックインする

　こちらの運用でも，すべての変更に対してビルドとテストを実施するのは同じです（図2）．結果が正常であった変更のみが構成管理ツールに追加されるので，構成管理ツール上のファイルは，すべてテストを通ったものであるという状態になります．

図2　ビルドとテストを通った変更のみをチェックインする（パターン2）

（パターン3）定期的なビルド（例えばウイークリー・ビルド）を自動化する

　構成管理とビルドは同期させずに，定期的なビルドを自動化するという運用もあります．この場合，定期的なビルドの開始時刻を指定しておき，使用するファイルは構成管理ツールで抽出します（図3）．つまり，決められた時刻の構成管理のスナップショットを作成し，それを基にビルドとテストを行うという方法です．必要な変更があるのにソース・コードの登録が間に合わない場合は，ビルド開始時刻を変更するようにビルド担当者に要求を出すこともできますが，ビルドが頻繁に行われている環境であれば，次回のビルドで盛り込むことができます．

図3　定期的なビルドを自動化する（パターン3）

　これらのパターンを組み合わせて運用する場合もあります．