配置をサポートするビルド定義を作成する
作成者: Jason Lee
Team Foundation Server (TFS) 2010 で任意の種類のビルドを実行する場合は、チーム プロジェクト内にビルド定義を作成する必要があります。 このトピックでは、TFS で新しいビルド定義を作成する方法と、チーム ビルドのビルド プロセスの一部として Web 配置を制御する方法について説明します。
このトピックは、Fabrikam, Inc. という架空の会社のエンタープライズ配置要件を題材にしたチュートリアル シリーズの一部です。このシリーズでは、サンプル ソリューション (Contact Manager ソリューション) を使用して、現実的なレベルの複雑さを持った、ASP.NET MVC 3 アプリケーション、Windows Communication Foundation (WCF) サービス、データベース プロジェクトなどを含んだ Web アプリケーションを取り上げます。
これらのチュートリアルの核心である配置方法は、「プロジェクト ファイルについて」で説明した分割プロジェクト ファイルのアプローチを基にして、ビルドと配置のプロセスを 2 つのプロジェクト ファイル (すべての配置先環境に適用されるビルド命令を含むファイルと、環境に特化したビルド設定や配置設定を含むファイル) で制御するものになっています。 ビルド時には、環境に特化したプロジェクト ファイルが環境に依存しないプロジェクト ファイルにマージされ、ビルド命令の完全なセットが形成されます。
タスクの概要
ビルド定義は、TFS のチーム プロジェクトにビルドが発生する方法とタイミングを制御するメカニズムです。 各ビルド定義では、次が指定されます。
- Visual Studio ソリューション ファイルやカスタム Microsoft Build Engine (MSBuild) プロジェクト ファイルなどの、ビルドしたいもの。
- 手動トリガー、継続的インテグレーション (CI)、ゲート チェックインなど、ビルドを実行するタイミングを決定する条件。
- チーム ビルドがビルド出力を送信する場所 (Web パッケージやデータベース スクリプトなどの配置成果物を含む)。
- 各ビルドを保持する必要がある合計時間。
- ビルド プロセスのその他のさまざまなパラメーター。
Note
ビルド定義の詳細については、ビルド プロセスの定義に関するページをご覧ください。
このトピックでは、開発者が新しいコンテンツをチェックインしたときにビルドがトリガーされるように、CI を使用するビルド定義を作成する方法について説明します。 ビルドが成功した場合、ビルド サービスはカスタム プロジェクト ファイルを実行して、ソリューションをテスト環境に配置します。
ビルドをトリガーするときは、次のアクションを実行する必要があります。
- まず、チーム ビルドでソリューションをビルドする必要があります。 このプロセスの一環として、チーム ビルドは Web 発行パイプライン (WPP) を呼び出して、ソリューション内の各 Web アプリケーション プロジェクトの Web 配置パッケージを生成します。 チーム ビルドでは、ソリューションに関連付けられている単体テストも実行されます。
- ソリューション ビルドが失敗した場合、チーム ビルドでは、それ以上のアクションは実行されません。 単体テストの失敗は、ビルドの失敗として扱う必要があります。
- ソリューションのビルドが成功した場合、チーム ビルドでは、ソリューションの配置を制御するカスタム プロジェクト ファイルを実行する必要があります。 このプロセスの一環として、チーム ビルドは、インターネット インフォメーション サービス (IIS) Web 配置ツール (Web 配置) を呼び出して、パッケージ化された Web アプリケーションをインストール先の Web サーバーにインストールし、VSDBCMD.exe ユーティリティを呼び出して、インストール先のデータベース サーバーでデータベース作成スクリプトを実行します。
このプロセスを次に示します。
Contact Manager サンプル ソリューションには、MSBuild またはチーム ビルドから実行できるカスタム MSBuild プロジェクト ファイル Publish.proj が含まれています。 「ビルド プロセスについて理解する」で説明されているように、このプロジェクト ファイルは、Web パッケージとデータベースをターゲット環境に配置するロジックを定義します。 このファイルには、これがチーム ビルドで実行されている場合にビルドとパッケージ化のプロセスを省略し、配置タスクのみを実行するロジックが含まれています。 これは、この方法で配置を自動化する場合、通常、ソリューションが正常にビルドされ、配置プロセスが開始される前にすべての単体テストに合格することを確認する必要があるためです。
次のセクションでは、新しいビルド定義を作成してこのプロセスを実装する方法について説明します。
Note
この、単一の自動化されたプロセスによってソリューションが構築、テスト、配置される手順は、テスト環境への配置に最も適していると考えられます。 ステージングおよび運用環境では、テスト環境で既に確認および検証済みの以前のビルドからのコンテンツを配置する可能性が高くなります。 この方法については、次のトピック「特定のビルドの配置」で説明します。
この手順を実行するユーザー
通常、TFS 管理者がこの手順を実行します。 場合によっては、開発者チーム リーダーが TFS のチーム プロジェクト コレクションの責任を負う場合があります。 新しいビルド定義を作成するには、ご自分のソリューションを含むチーム プロジェクト コレクションのプロジェクト コレクション ビルド管理者グループのメンバーである必要があります。
CI と配置のビルド定義を作成する
次の手順では、CI によってトリガーされるビルド定義を作成する方法について説明します。 ビルドが成功すると、カスタム MSBuild プロジェクト ファイル内のロジックを使用してソリューションが配置されます。
CI と配置のビルド定義を作成するには
Visual Studio 2010 の [チーム エクスプローラー] ウィンドウで、チーム プロジェクト ノードを展開し、[ビルド] を右クリックし、[新しいビルド定義] を選択します。
[全般] タブで、ビルド定義に名前 (DeployToTest など) とオプションの説明を指定します。
[トリガー] タブで、新しいビルドをトリガーする条件を選択します。 たとえば、開発者が新しいコードでチェックインするたびにソリューションをビルドし、テスト環境に配置する場合は、[継続的インテグレーション] を選択します。
[ビルドの既定値] タブの [ビルド出力を次の格納フォルダーにコピーする] ボックスに、格納フォルダーの汎用名前付け規則 (UNC) パス (\TFSBUILD\Drops など) を入力します。
Note
この格納フォルダーには、構成したアイテム保持ポリシーに応じて、いくつかのビルドが保存されます。 特定のビルドからステージングまたは運用環境に配置成果物を発行する場合は、ここで見つけることができます。
[プロセス] タブの [ビルド プロセス ファイル] ドロップダウン リストで、DefaultTemplate.xaml を選択したままにします。 これは、すべての新しいチーム プロジェクトに追加される既定のビルド プロセス テンプレートの 1 つです。
[ビルド プロセス パラメーター] テーブルで、[ビルドする項目] 行を選択し、省略記号ボタンを選択します。
[ビルドする項目] ダイアログ ボックスで、[追加] を選択します。
ソリューション ファイルの場所を参照し、[OK] を選択します。
[ビルドする項目] ダイアログ ボックスで、[追加] を選択します。
[種類の項目] ドロップダウン リストで、[MSBuild プロジェクト ファイル] を選択します。
配置プロセスを制御するカスタム プロジェクト ファイルの場所を参照し、ファイルを選択して、[OK] を選択します。
[ビルドする項目] ダイアログ ボックスに 2 つの項目が表示されます。 OK をクリックします。
[プロセス] タブの [ビルド プロセス パラメーター] テーブルで、[詳細設定] セクションを展開します。
[MSBuild 引数] 行に、ビルドする "いずれか" の項目に必要な MSBuild コマンド ライン引数を追加します。 Contact Manager ソリューション シナリオでは、次の引数が必要です。
/p:DeployOnBuild=true;DeployTarget=Package; TargetEnvPropsFile=EnvConfig\Env-Dev.proj
次の点に注意してください。
- Contact Manager ソリューションをビルドするときは、DeployOnBuild=true と DeployTarget=package 引数が必要です。 これにより、MSBuild に「Web アプリケーション プロジェクトのビルドとパッケージ化」の説明に従って、各 Web アプリケーション プロジェクトをビルドした後に Web 配置パッケージを作成することが指示されます。
- Publish.proj ファイルをビルドするときは、TargetEnvPropsFile 引数が必要です。 このプロパティは、「ビルド プロセスについて理解する」に説明されているように、環境固有の構成ファイルの場所を示します。
[アイテム保持ポリシー] タブで、必要に応じて保持する種類ごとのビルドの数を構成します。
[保存] をクリックします。
ビルドをキューに配置する
この時点で、少なくとも 1 つの新しいビルド定義を作成しました。 これで、定義したビルド プロセスは、ビルド定義で指定したトリガーに従って実行されます。
CI を使用するようにビルド定義を構成した場合は、次の 2 つの方法でビルド定義をテストできます。
- チーム プロジェクトにいくつかのコンテンツをチェックインして、自動ビルドをトリガーする。
- ビルドを手動でキューに配置する。
ビルドを手動でキューに配置するには
[チーム エクスプローラー] ウィンドウで、ビルド定義を右クリックし、[新しいビルドをキューに配置] を選択します。
[ビルドをキューに配置] ダイアログ ボックスで、ビルドのプロパティを確認し、[キュー] を選択します。
ビルドの進行状況と結果を確認するには、ビルドがトリガーされたのが手動か自動かに関わらず、[チーム エクスプローラー] ウィンドウでビルド定義をダブルクリックします。 [ビルド エクスプローラー] タブが開きます。
ここから、失敗したビルドのトラブルシューティングを行うことができます。 個々のビルドをダブルクリックすると、概要情報が表示され、選択すると詳細なログ ファイルに移動できます。
この情報を使用して、失敗したビルドのトラブルシューティングを行い、別のビルドを試みる前に問題に対処できます。
Note
配置ロジックを実行するビルドは、ビルド先の環境でビルド サーバーに必要なアクセス許可を付与するまで失敗するおそれがあります。 詳細については、「チーム ビルド配置のアクセス許可を構成する」をご覧ください。
ビルド プロセスを監視する
TFS には、ビルド プロセスの監視に役立つ広範な機能が用意されています。 たとえば、TFS からメールを送信したり、ビルドが完了したときにタスク バーの通知領域にアラートを表示したりできます。 詳細については、ビルドの実行と監視に関するページをご覧ください。
まとめ
このトピックでは、TFS でビルド定義を作成する方法について説明しました。 ビルド定義は CI 用に構成されているため、開発者がチーム プロジェクトにコンテンツをチェックインするたびにビルド プロセスが実行されます。 ビルド定義は、カスタム MSBuild プロジェクト ファイルを実行して、Web パッケージとデータベース スクリプトをターゲット サーバー環境に配置します。
ビルド プロセスの一環として自動配置を成功させるには、ターゲット Web サーバーとターゲット データベース サーバー上のビルド サービス アカウントに適切なアクセス許可を付与する必要があります。 このチュートリアルの最後のトピック「チーム ビルド 配置のアクセス許可を構成する」では、チーム ビルド サーバーからの自動配置に必要なアクセス許可を識別して構成する方法について説明します。
もっと読む
ビルド定義の作成の詳細については、基本的なビルド定義の作成、およびビルド プロセスの定義に関するページをご覧ください。 ビルドのキューへの登録に関する詳細なガイダンスについては、「ビルドのキューへの登録」をご覧ください。