連続的なビルドおよび配置

  • [アーティクル]

多くの開発者が共同で作業する複雑なソフトウェア プロジェクトでは、異なる部分のコードを 1 つに統合するプロセスに時間がかかるうえ、予期しない結果が生じることがあります。 ただし、プロジェクトを継続的にビルドおよび配置することで、このプロセスの効率と信頼性を高めることができます。

継続的インテグレーション (CI) とは、共有リポジトリにコードを統合する回数をできる限り増やすというプロセスです。 コードの統合時に、ビルド ブレークまたはテストの失敗を通じて、コードのエラーを適時に認識することができます。

Martin Fowler 氏は、継続的インテグレーションのやり方を次のようにまとめています。

  • ソース リポジトリを 1 つにする。

  • ビルドを自動化する。

  • ビルドが自動的に継続するようにする。

  • 少なくとも 1 日に 1 回はチェックインする。

  • チェックインごとに CI サーバー上でビルドを実行する。

  • ビルドを高速に保つ。

  • テストは稼働環境の複製で行う。

  • 最新の実行可能ファイルをだれもが簡単に入手できるようにする。

  • 何が行われているかについて常にわかるようにする。

  • 配置を自動化する。

詳細については、Martin Fowler 氏の Web サイトの「Continuous Integration (継続的インテグレーション)」を参照してください。

Visual Studio アプリケーション ライフサイクル管理 (ALM) は、ソフトウェア開発のエンド ツー エンド プロセスを管理するのに役立つうえ、継続的インテグレーションの手法をサポートしています。 プロジェクトで Visual Studio ALM の機能を利用することで、予期しない遅延、コスト超過、および実行時のリスクを回避できます。

このトピックの内容

  • 依存関係の管理

  • Visual Studio 2010 の継続的インテグレーション

  • 準備と開始

  • バージョン コントロール

  • ビルド

  • テストと配置

  • プロジェクトの統合とコミュニケーション

依存関係の管理

コードの統合を複雑なプロセスにしているのは、コード間の依存関係です。 たとえば、画面上に円を描画するライブラリは、システムの数値演算ライブラリの Sqrt() メソッドに依存します。 Sqrt() メソッドが変更されたら、それに応じてライブラリを更新する必要があります。 ハードウェアやオペレーティング システムはチーム プロジェクトほど頻繁には変更されませんが、 どのような場合であっても変更を無視すると、悲惨な結果を招くことになります。 コードをできるだけ早い段階で統合することで、前提が適切であるかどうかや計画どおりに機能するかどうかを調べることができます。

コードの変更が依存関係に及ぼす影響はほかにもあります。 次の図に、2 つの状況を示します。 左側の例は、比較的孤立した変更を示しています。 一方、右側の例は、依存関係が多いために潜在的により大きな影響がある変更を示しています。

コードの連続的なビルドおよび配置の図

次の図は、コードの継続的な統合およびアップグレードを行わなかった場合に、一定の変更によってどのように複合的な影響が及ぶかを示したものです。

コードの連続的なビルドおよび配置のタイムライン

ステップ 1 で、コード ブロック h を変更します。これにより、依存しているすべてのコード ブロック a、b、d、e、および f が影響を受ける可能性があります。 ステップ 2 で、コード ブロック a および b の 2 つを変更します。 チームがステップ 1 とステップ 2 の間で統合を行っていなければ、ブロック a および b はもはや有効ではない可能性があります。 ステップ 3 で、コード ブロック f を変更します。 チームがステップ 2 とステップ 3 の間で統合を行っていないとすると、この時点でコード ブロック b は、影響を受け、変更され、再び影響を受けたことになります。 その結果、コード ブロック b の修正が困難になることが考えられます。

Visual Studio 2010 の継続的インテグレーション

Visual Studio ALM には、継続的インテグレーションをサポートするための統合されたツールセットが用意されています。次の図に示すように、これらのツールには、バージョン コントロール、ビルド、テスト、ラボ環境への配置、作業項目トラッキング、およびデータ ウェアハウジング機能が含まれます。

連続的なビルドおよび配置における TFS

まず、Team Foundation バージョン管理を使用して、分岐、変更セット、およびそれらの間の統合を管理できます。 各チーム メンバーは、ワークスペースを使用することで独立して作業できます。 詳細については、「分岐とマージ」および「ワークスペースの作成とチーム プロジェクトの操作」を参照してください。

第 2 に、Team Foundation ビルドを使用して、自動化された分散システムでソフトウェアをコンパイル、テスト、および配置できます。 前の図の Team Foundation ビルドには、2 種類のビルドがあります。 一方は、継続的ビルド タイプを使用して開発分岐をビルドし、もう一方はゲート チェックイン ビルドを使用して Main 分岐をビルドしています。 Visual Studio Team Foundation Server では、手動、継続的 (チェックインごとにトリガーされます)、ロール (前のビルドが完了するまでチェックインを蓄積します)、ゲート チェックイン、およびスケジュールの 5 種類のビルドをサポートしています。 詳細については、「基本的なビルド定義の作成」、「Team Foundation ビルド システムについて」、および「ゲート チェックイン ビルドによって制御されている保留中の変更内容のチェックイン」を参照してください。

第 3 に、Visual Studio ALM のラボ管理で、物理的ラボ環境と仮想ラボ環境の両方にビルドを定義して配置できます。 特定の環境における実行時の統合エラーを捕捉するには、ラボ環境にビルドを配置し、そのビルドでテスト スイートを実行します。 詳細については、「アプリケーションのライフサイクルでの仮想ラボの使用」を参照してください。

また、Visual Studio ALM のテスト機能をチーム メンバーのコンピューター上、ビルド コンピューター上、およびラボ環境内で利用できます。 最初に、開発者のコンピューター上でテスト スイートを実行して、最近変更または作成されたコードに関連する問題を捕捉します。次に、ビルド コンピューター上でテストを実行して、他のコードとの統合に関連する問題を捕捉します。 最後に、ラボでテストを実行して、チームが構成する特定の環境に関連する問題を捕捉します。 詳細については、「方法: アプリケーションのビルド後にスケジュールされているテストを構成および実行する」を参照してください。

注意

テストを実行すると、コード カバレッジ メトリックを生成できます。これを使用すると、テスト ケースでカバーできるコードの量を把握できます。 ただし、コード カバレッジは、テストの完全性または品質を測定する目的には使用できません。 詳細については、「方法: 自動テストのテスト設定を使用してコード カバレッジを構成する」を参照してください。

第 4 に、作業項目を格納するリポジトリとして Visual Studio Team Foundation Server を使用できます。 チーム メンバーに割り当てられるバグやタスクなどの作業項目を作成、管理、および追跡できます。 コードの統合時にビルド ブレークが発生した場合、チームは、できる限り迅速に問題を修正する必要があります。 Team Foundation Server を構成して、ビルド ブレーク用の作業項目を作成できます。 詳細については、「バグ、タスク、およびその他の作業項目の追跡」を参照してください。

最後に、Team Foundation Server および SQL Server Analysis Services 用のウェアハウスのデータベースで、Team Foundation Server のサブシステムから提供されるすべてのデータを集約して関連付けます。 これらのサブシステムには、バージョン コントロール、ビルド、テスト、配置、および作業項目トラッキングが含まれます。 これにより、チームは、継続的インテグレーションのエンド ツー エンド プロセスを視覚化することができます。詳細については、「Visual Studio ALM 用のリレーショナル ウェアハウス データベースを使用したレポートの生成」を参照してください。

準備と開始

チームは、次のような流れで、継続的インテグレーションと Team Foundation Server の使用を開始できます。

  1. Team Foundation バージョン管理を使用して、コードを 1 つのコード ベースに統合します。

  2. Team Foundation ビルドで手動ビルドを作成します。

  3. 自動化されたテスト ケースを実行して、ビルドの品質を確認します。 適切なテスト スイートがない場合は、プレースホルダー テスト スイートを作成し、いくつかの自動化されたテスト ケースをインポートします。 このスイートを、以降のテストのプレースホルダーとして使用できます。

  4. ビルドからの結果のバイナリを共有の場所に配置します。 こうすることで、テスト中に発見される問題を診断するのに役立ちます。

  5. Microsoft テスト マネージャー を使用して、特定の環境における実行時の統合エラーを捕捉します。

バージョン コントロール

バージョン コントロール システムは、コードの共有リポジトリになります。 小規模なチームであれば 1 つの分岐で作業することもできますが、 通常は複数のバージョンのコードを開発してさまざまなマイルストーンでプロジェクトをリリースしなければならないため、複数の分岐で作業する方が適しています。 コード分岐の作成およびマージ方法の詳細については、CodePlex の Web サイトの「Team Foundation Server Branching Guide 2.0 (Team Foundation Server 分岐ガイド 2.0)」を参照してください。

ビルド

継続的インテグレーションにおいて、ビルド システムは、テストおよび配置できる実行可能ファイル コンポーネントを生成します。 ビルド システムからは、コンパイル エラーおよび警告の形でフィードバックも返されます。 これらのエラーは、プロジェクト ソースに加えられた変更が原因で発生します。

Team Foundation ビルドには、次のビルドの種類が用意されています。

  • 手動: チーム メンバーによってビルドがキューに入れられます。

  • 継続的: バージョン コントロールの分岐にチェックインすることでビルドがキューに入れられます。

  • ロール: 前のビルドが完了するまでビルドが蓄積されます。

  • ゲート チェックイン: 送信された変更が正常にマージされ、ビルドされる場合にのみ、チェックインが受け入れられます。

  • スケジュール: 定義されたスケジュールでビルドが実行されます。

詳細については、「基本的なビルド定義の作成」を参照してください。

継続的インテグレーションを正常に実装するためにチーム メンバーから期待されること

チーム メンバーは、10 分以内にビルドを実行できるようにソースを整理しておく必要があります。 大きなプロジェクトの場合、これは不可能なことがあります。 Team Foundation Server を使用すると、さまざまなビルド定義を構成して、コード ベースの異なるサブセットをビルドできます。 ビルドに時間がかかる場合は、ロール ビルドを使用して、変更がないコードのバイナリを連続的に生成できます。

ビルド ブレークが発生した場合、チームは即座にビルドを修正する必要があります。 メイン分岐が不適切な逆方向の統合の影響を受けないと仮定した場合、ほとんどのビルド ブレークは、作業分岐での不適切なチェックインか、またはメインライン分岐からの順方向の統合に原因があります。 ビルド ブレークを修正するタスクは、期間を決めてチーム メンバーに割り当て、チーム メンバー間で持ち回り制にすることをお勧めします。

1 日に何回ビルドを実行する必要があるか

コードを継続的に統合する場合は、あらゆる分岐で発生するチェックインごとに継続的ビルドを実行します。 新たにチェックインされたコードとは別に、独立したロール ビルドを実行することもできます。 詳細については、「基本的なビルド定義の作成」および「実行中のビルドの進行状況の監視」を参照してください。

Team Foundation Server を使用してどのようにコードのビルドを高速化できるか

インクリメンタル ビルドを実行するビルド定義を構成することで、ビルドを高速化できます。 ビルド ログを使用すると、改良の余地があるビルドの低速な部分を識別できます。 詳細については、「インクリメンタル ビルド用の Team Foundation ビルドの構成」を参照してください。

Team Foundation ビルドを使用してどのように継続的インテグレーションをスケーリングできるか

ビルド コントローラーとビルド エージェントを使用することで、継続的インテグレーション サイクルをスケーリングできます。

詳細については、「Team Foundation ビルド システムについて」を参照してください。

テストと配置

テストと配置を継続的インテグレーションにどのように適合させることができるか

Visual Studio ALM のテストと配置の機能が継続的インテグレーションにどのように適合されるかを次の図に示します。

継続的なインテグレーションへのテストの調整

まず、継続的にコードを統合することで、ビルド自体のコードの問題を見つけることができます。 使用したコンパイラでビルドのコンパイルが成功するか失敗した後、 コンパイラからのエラー メッセージと警告メッセージの両方を含むビルド レポートを生成することができます。 また、Visual Studio ALM のビルド レポートには、このビルドでどのバグが修正されたか、このビルドにどの変更セットが含められたか、ビルド中にコード分析が実行されたかどうか、などの情報も含まれています。 Visual Studio ALM を使用することにより、コードの設計がチームで定義した規則に従っているかどうかを確認できます。 詳細については、「方法: レイヤー図と照らし合わせて .NET コードを検証する」を参照してください。

次に、単体テストを実行してコードの問題を見つけることができます。 これらのテストでは、コンパイラとは別の問題を診断します。 コンパイラの規則では、コードの構文や言語構成要素に関する問題がチェックされます。 これに対し、(ビルドが完了した後にビルドに対して実行できる) 単体テストでは、コードの機能面を検証できます。 このような単体テストでは、単体テストのセットを使用して、ビルドのコード カバレッジのようなメトリックも提供できます。 詳細については、「方法: 自動テストのテスト設定を使用してコード カバレッジを構成する」を参照してください。

Microsoft テスト マネージャー を使用すると、テストを実行できる特定の環境を構成できます。 単体テストを個別に実行することで、機能的検証の 1 つのレベルが提供されます。 ただし、環境に関して、次の重要な側面を考慮する必要があります。

  • 環境が変わるとコードの動作も変わります。 たとえば、ラボ管理環境がないと、ネットワークの設定およびトポロジをテストするのは困難です。

  • 特定の環境におけるコードの配置を自動化すると、チームは、配置するまでの時間を短縮する一方で、配置イテレーションの数を増やすことができます。

詳細については、「How to: Create an Environment from Virtual Machine Templates」および「テスト コンピューターでのテストの実行またはデータの収集の設定」を参照してください。

継続的インテグレーションを実現するためにテスト スイートをどのように整理すればよいか

継続的なビルドにとって最も重要なテスト スイートを実行するようにします。テストが多すぎるとビルドの完了が遅れる可能性があるからです。 これらのテストは現在のイテレーションに対して実行するようにしてください。

前のビルドのテスト、および前のスプリントの機能を検証する完全なテスト パスは、夜間ビルドまたはスケジュールされたビルド サイクルで実行することもできます。

継続的インテグレーションはテスト チームにどのような影響をもたらすか

継続的インテグレーションでは、エラーが含まれるビルドを識別できるため、テスト チームが不適切なビルドの操作やインストールに時間を無駄に費やすことがなくなります。

プロジェクトの統合とコミュニケーション

継続的インテグレーションを実装するための労力は、プロジェクトのサイズに大きく依存します。 継続的インテグレーションの作業は、プロジェクトの最初のスプリントで定義およびスケジュールする必要があります。

継続的インテグレーションを段階的に導入する場合は、自動化されたビルドの実装から開始します。 その後、単体テストの実行を含めるように変更します。 最後に、テストしたビルドをラボ環境に配置する機能を追加し、環境内でテストを実行して、環境が変わってもコードに影響が出ないかどうかを確認します。