組織に継続的インテグレーションを導入していく7つの段階

みなさんこんにちは。@ryuzeeです。

継続的インテグレーションの導入に関する分かりやすい記事があったので抜粋・意訳にてご紹介します。原文はJohn Ferguson Smart氏のブログ記事「The Seven Phases of Introducing Continuous Integration into Your Organization」です。

継続的インテグレーションは全部かゼロかといった類のものではない。事実、CIの組織への導入はいくつかの明確な段階を経て進んでいくのだ。それぞれの段階は技術的な構造もそうだが、それ以上に重要であるであろう開発チーム自体のプラクティスや文化のインクリメンタルな改善を含んでいる。以下の章では各段階についておおよその全体像を示すことにしよう。

第1段階ビルドサーバがない

初期の段階ではチームはなんらの中央ビルドサーバも持ちあわせていない。ソフトウェアは開発者のマシン上で手動でビルドされる。たぶんAntのスクリプトや似たようなスクリプトを使っているだろう。ソースコードは中央のコードレポジトリに格納されているが、開発者は定常的に変更をコミットする必要にはさらされていない。リリースが予定される少し前になると、開発者は手動で変更を統合する。このプロセスは一般的に苦痛で不快がつきものだ。

第2段階夜間ビルド

この段階では、チームはビルドサーバを持っており、定期的な自動ビルド(多くの場合は夜間だ)がスケジューリングされている。ここでは単にコードをコンパイルし、一方でなんらの信頼できる繰り返し可能なユニットテストは用意されていない。実際のところ、もしチームが自動化されたテストを書いていた場合でも、自動化されたテストはビルドプロセスの必須の要素にはなっておらず、一度に正しく実行されることもない。しかし開発者は頻繁に(少なくとも一日の終わりには)コードをコミットしている。開発者がソースコードをコミットしたとき、他の開発者の作業とコンフリクトしていた場合には、ビルドサーバは翌日の朝にチームに対してメールで警告を送信する。そうはいうものの、チームはまだビルドサーバを情報提供目的のみで使っており、壊れたビルドを素早く修正することに対して義務感を感じたり、ビルドがしばらくの間壊れたままだったりする。

第3段階夜間ビルドと基本的な自動化されたテスト

この段階になるとチームは継続的インテグレーションと自動化されたテストについてより重要なものとしてとらえるようになっている。ビルドサーバは、新しいコードがバージョン管理システムにコミットされるとビルドプロセスが開始されるように設定されており、チームメンバーは特定のビルドがどのコードの変更によって行われたものなのか、変更内容のどこに問題があるのかについて容易に把握可能になる。加えてビルドスクリプトはソースコードをアプリケーションとしてコンパイルし、自動化されたユニットテストや統合テストを実行する。さらにはメールに加えて、ビルドサーバは統合における問題について、よりプロアクティブなチャネル(例えばインスタントメッセンジャー)への通知も行われる。壊れたビルドは速やかに修正される。

第4段階メトリクスの導入

自動化されたコード品質やコードカバレッジのメトリクスがコード品質や（少なくともある程度は）テストの妥当性や効果の評価のために実行される。コード品質確認用のビルドでは、アプリケーションのAPIドキュメントも自動生成する。これらすべてはコードベースの品質を高く保ったり、テストが失敗した場合のチームメンバーへの警告に役にたつ。チームはさらにはプロジェクトの状況を派手な画面上にみながみえるように表示したダッシュボードである「ビルドラジエータ」を準備したりする

第5段階よりテストに対して慎重になる

CIの利点はしっかりしたテスティングプラクティスと密接な関係がある。テスト駆動開発のようなプラクティスはより広く取り入れられており、結果として自動化されたビルドにおける信頼性が増すことになる。アプリケーションはもはや単純にコンパイルしてテストするのではなく、もしテストにパスしたら、より総合的なエンドツーエンドテストやパフォーマンステストのためにアプリケーションサーバに自動でデプロイするのだ。

第6段階自動化された受け入れテストとより自動化されたデプロイ

受け入れテスト駆動開発も取り組まれている。受け入れテスト駆動開発は開発の方向性の道しるべとなり、またプロジェクトの高レベルでの状況報告となりえる。これら自動化されたテストにおいては、振る舞い駆動開発(BDD)の手法や受け入れテスト駆動開発用のツール(これらはコミュニケーション用のツールとしてもドキュメンテーション用のツールとしても利用され、開発者以外でも理解できるような口語の文書によるレポートを生成したりもする)が利用される。これらの高次元のテストが開発プロセスの初期段階から自動化されていると、それらのテストはどのフィーチャーが実装されたかやどれが残っているかについてのはっきりした状況を提供してくれる。アプリケーションはQAチームのテストのために変更がコミットされるごと、もしくは夜間に定期的にテスト環境に自動でデプロイされている。テスターが大丈夫だと判断したら手動でトリガーを引いてUAT環境や可能ならプロダクション環境にデプロイされる。チームはビルドサーバをリリースを取り消して過去のリリースにロールバックする用途にも使うことができる。

第7段階継続的デプロイ

自動化されたユニットテスト、インテグレーションテスト、受け入れテストによってアプリケーションが確かであることを確認できるようになっていることは、過去のフェーズで作成した変更点を直接プロダクション環境に反映する仕掛けを自動化できるということにつながる。

最後に

ここで述べたレベルの経過はもちろんおおよそのものであり、常に現実の状況にマッチするとは限らない。例えばコード品質やコードカバレッジのレポートの自動化の前に自動化されたWebテストを用意するかもしれない。しかし上記の話はどうやって継続的インテグレーションを自分たちの組織でうまく作用するように実現するかという戦略についての一般的なアイデアを与えてくれるだろう。

それでは。