Team System
Team Build 2008
Brian A. Randell
目次
Team Foundation Server (TFS) はチームに関するものです。確かにチームでこれを使用できますが、TFS の本質は、実際には開発プロジェクトにおける他の人とのコラボレーションです。
ビルドの自動化は F5 ではありません。ビルドの自動化は、収集、アセンブル、検証、および監査に関するものです。その概念は、ソリューションを構成するすべてのアーティファクトを収集し、明確に定義された統合計画に基づいてそのアーティファクトをアセンブルすることです。コンパイルは、アセンブル フェーズで定義される典型的なタスクです。ビルド確認テスト (BVT) またはスモーク テストと呼ばれることの多いさまざまな種類の自動テストを使用して、チームの全体的な作業を検証します。
最後に、何らかの種類の監査を実行して、ビルドの全体的な品質を評価します。監査は、難しい質問に答えるためのデータを提供するのに役立ちます。たとえば、このビルドでは製品を作成しますか。製品は高品質ですか。退行したものはありますか。スケジュールどおりですか。ビルド監査の価値は、チームの脈拍を簡単に測れることです。
このコラムでは、Visual Studio 2008 Team Foundation Server ビルド (Team Build) を紹介し、チーム ビルドを作成および実行するプロセスについて説明します。Team Build 2008 でプログラミングするために使用可能なマネージ API についても示します。
Team Build について
Team Build は TFS 2008 の中核となる機能です。マイクロソフトは、非常に強力なビルド自動化ツールとなるようにこれをデザインしました。Team Build によってチームの F5 エクスペリエンスが提供されます。通常の環境では、Team Build を独自の専用サーバーにインストールします (ただし、チームが非常に小規模であるか予算が厳しい場合は、TFS ボックスに Team Build をインストールできます)。
TFS の他の部分とは異なり、Team Build の 2008 リリースはメジャー アップデートです。2005 リリースで、マイクロソフトは優れたビルド自動化製品を作成しました。MS-Build をエンジンとして使用した Team Build 2005 は、バージョン管理、コンパイル、複数ビルド タイプ、単体テスト、静的分析、コード カバレッジなど、期待される中核自動化機能の多くをサポートしていました。
また、過去の傾向分析をサポートするために、ビルド レポートや TFS データ ウェアハウスへのデータ更新などの優れたレポート機能も提供されます。Team Build の 2005 リリースでは、複数ビルド コンピュータ、ビルド通知、およびコマンドラインまたはチーム エクスプローラ ユーザー インターフェイスからビルドを開始する機能もサポートされていました。
Team Build 2008 では、マイクロソフトは単なる機能強化を超えることを行いました。大きな拡張として、継続的な統合サポート、ビルド キューイング、チーム エクスプローラによるスケジュールされたビルド、およびマネージ オブジェクト モデルがあります。また、ビルド定義からビルド エージェント定義を分離し、ビルド定義編集ユーザー インターフェイスを作成し、より優れたビルド管理ツールを追加しました。
堅固な Team Build 2005 機能セットと組み合わせて、Team Build 2008 は魅力的なビルド自動化ソリューションを提示します。また、マイクロソフトは下位互換性のサポートを継続するため、開発チームがまだ Visual Studio 2005 を使用している場合でも、TFS インストール環境と Team Build サーバーをアップグレードできます。
チーム ビルドを作成する
Team Build を使用するには、当然ながら、シングル サーバー構成またはデュアル サーバー構成で TFS をインストールする必要があります。Team Build をインストールし、ビルド サーバーを正しく構成する必要があります。詳細については、最近更新された「
Team Foundation インストール ガイド」に記載されています。最後に、バージョン管理リポジトリにコードがチェックインされたチーム プロジェクトが必要です。
Team Foundation Server クライアントがインストールされた Visual Studio 2008 で、チーム プロジェクトを読み込んだチーム エクスプローラ ウィンドウを開きます。この例では、MSF-Agile テンプレートを使用して、MSDNMag というチーム プロジェクトを作成したと仮定します (詳細を確認するには、このコラムの
コードと
Team System 2008 TFS および Team Suite Virtual PC イメージをダウンロードしてください)。この例では、MSDNMag というカスタム ワークスペースを、Virtual PC イメージの C:\Work にマップされた樹幹と共に使用します。
すべて揃ったら、チーム エクスプローラ ウィンドウで MSDNMag チーム プロジェクト ノードを展開し、[ビルド] フォルダを探すことができます。[ビルド] フォルダを右クリックすると、いくつかのオプションが表示されます。この時点で関係するのは、[ビルド定義の新規作成] コマンドです。選択すると、[ビルド定義] ダイアログが表示されます (図 1 を参照)。
.gif)
図 1 空白の [ビルド定義] ダイアログ (クリックすると拡大画像が表示されます)
Team Build 2005 のウィザードとは異なり、ビルド定義を編集する必要がある場合は、このダイアログに戻ることができます。まず、SimpleBuildExplorer-OnDemand などのビルド名を指定します。また、[このビルド定義を無効にする] オプションをオンにすることで、ビルドをオフラインに保つことができます。
新しいビルドを作成する場合は、ビルド定義名と Team Build プロジェクト ファイルを入力し、ビルド エージェントとドロップ場所を指定する必要があります。ただし、筆者の個人的な意見では、2 つ目のオプションである [ワークスペース] が重要です。
Team Build 2005 では、[ワークスペース] オプションを知っておく必要がありました。実装の詳細は変更されましたが、目的は同じです。つまり、ビルド プロセスのソース取得ステップ中に Team Build がダウンロードするアーティファクトを制限することです。Team Build 2005 では、WorkspaceMapping.xml というファイルを変更する必要がありました。Team Build 2008 では、バージョン管理のワークスペース マッピングのダイアログにあるのと同様の GUI を使用します (図 2 を参照)。
.gif)
図 2 [ビルド定義] ダイアログの [ワークスペース] ページ (クリックすると拡大画像が表示されます)
ワークスペースでは、ビルドの一部として使用するソース コード リポジトリのセクションを定義します。既定では、Team Build はチーム プロジェクトの樹幹をビルドで使用されるソース ダウンロードの場所 (ビルドを実行するビルド エージェントをビルド定義に関連付けるときに制御できます) にマップします。明確化のために、この設定を調整しない場合は、ビルドを実行するたびに、Team Build は樹幹に対して取得を実行して、すべて最新のものを取得します。デモやテストを行う場合には大きな問題になりませんが、チーム プロジェクトと複数のブランチで 6 か月間作業した後では、ビルドの実行は最善の方法ではありません。
ここでのデモ シナリオで使用する Visual Studio ソリューションは 1 つのみですが、それでもマッピングを調整する必要があります。[ソース管理フォルダ] 列の最初のアイテムをクリックすると、制限されたパスを入力するか、[フォルダの参照] ダイアログを使用することができます。この例では、[ソース管理フォルダ] を $/MSDNMag/Main/src/TeamSystem/C08 に設定しました。
バージョン管理ワークスペース マッピングで使用したダイアログでの場合と同様に、複数のフォルダ マッピングを定義できます。変数 $(SourceDir) は、Team Build が、ビルド エージェントのプロパティ ダイアログでビルド エージェントに対して指定されたビルド ディレクトリに展開する環境変数です。一般には、パスが相対になるように $(SourceDir) を使用します。ただし、Team Build はその使用を強制しません。この例では、現状のままにしています。
最後に、すべてのマッピングが希望どおりに構成された既存のワークスペースがある場合は、[既存のワークスペースのコピー] オプションを使用して、マッピングのバージョン管理フォルダ部分をコピーして時間を節約できます。
ワークスペース設定を定義した後で、ビルド プロジェクト ファイルを定義する必要があります。[プロジェクト ファイル] オプションをクリックすると、既にバージョン管理されている既存の TFSBuild.proj ファイルへのパスを指定できます。TFSBuild.proj は、2005 リリースではすべてのビルド構成データを含んだ XML ファイルであり、実際のビルド プロセスを拡張するようにカスタマイズしたファイルでした。Team Build 2008 では、引き続きビルド カスタマイズにこのファイルを使用しますが、ビルド定義に関連するほとんどのデータは TFS データベースに格納されます。ファイルがまだない場合は、[作成] ボタンをクリックし、単純なウィザードを使用して作成します。
Team Build 2008 での 1 つの大きな変更は、TFSBuild.proj ファイルを格納する場所を指定できるようになったことです。Team Build 2005 では、バージョン管理リポジトリの特定の場所にパスがハードコーディングされていました。既定では、Team Build 2008 ダイアログで、Team Build 2005 互換のパスが %TeamProjectName%/TeamBuildTypes/%BuildDefinitionName% の形式で指定されます。
この現在の例では、提案されるバージョン管理フォルダは $/MSDNMag/TeamBuildTypes/SimpleBuildExplorer-OnDemand となります。パスを変更できることの主な利点は、TFSBuild.proj ファイルを他のアーティファクトと分岐できることです。この例では、既定のパスを受け入れ、[作成] ボタンをクリックします。
[作成] ボタンをクリックすると、ウィザードが表示されます。ウィザードは、Team Build 2005 リリースの UI のうち残された数少ないものの 1 つです。最初のページでは、ビルドする Visual Studio ソリューションの選択を求められます。ウィザードは、表示されるリストをワークスペース マッピングに関連して使用可能なソリューションのみにフィルタします。既定のワークスペース マッピングを変更しない場合は、チーム プロジェクト内のすべてのソリューションが表示されます。提示される 1 つのソリューションを選択し、[次へ] をクリックします。
ウィザードの 2 ページ目では、ビルドする Visual Studio 構成の種類を選択できます。ウィザードでは構成に対して [デバッグ] と [リリース] のみ表示されますが、カスタム構成を入力できます。プラットフォームにも同じルールが適用されます。既定を受け入れて、[次へ] をクリックします。
ウィザードの最後のページでは、テストと静的分析の実行を制御します。テスト実行と静的分析が機能するためには、VSTS をビルド エージェント コンピュータにインストールする必要があります。Team Build 2005 リリースで可能だったのと同様に、テスト メタデータ ファイルを選択し、ここから無人実行をサポートするテスト リストを選択できます。ただし、Team Build で MSTest 互換テストの出力アセンブリを自動的にスキャンし、テスト リストを必要とすることなくそれらを実行することも選択できます。1 つ以上の Visual Studio プロジェクトで静的分析を有効にしていた場合は、Team Build で静的分析を実行することも選択できます。このコラムのサンプル ソリューションにはテストまたは静的分析がないため、[完了] をクリックしてウィザードを完了し、TFSBuild.proj ファイルを作成します。
この時点で必要なのは、ビルドの既定値を入力することだけです。まず、保持ポリシーとトリガ設定を見てみましょう。Team Build 2005 リリースに比べて大きく強化された Team Build 2008 では、ビルド定義保持ポリシーを構成できるようになりました (図 3 を参照)。特定のビルドの結果に基づいて、Team Build で保持するビルド結果の数を制御できます。
.gif)
図 3 ビルド定義保持ポリシーの制御 (画像をクリックすると拡大表示されます)
ビルドが完了した後で、保持ポリシーに関係なく Team Build で保持されるようにビルド結果をマークできます。この例では、保持ポリシーを既定の設定のままにする必要があります。
Team Build 2008 の [トリガ] オプションをクリックした場合は、Team Build 2005 と同様に動作します。つまり、要求したときにのみビルドが実行されます。ただし、現在は、Team Build で継続的な統合 (CI) もサポートされます (CI の詳細については、2008 年 3 月号の記事「
継続的な統合でビルド プロセスを再定義する」を参照してください)。これは、だれかがビルド定義のワークスペース マッピングによってマップされたファイルに対する変更をチェックインするたびに、ビルドがキュー登録されることを意味します。ダイアログでは、[チェックインのたびにビルドする (ビルド数多)] オプションでこの機能が公開されます。
2 つ目のオプションである [前のビルドの完了までチェックインを蓄積する (ビルド数少)] では、遅延形式の CI が提供されます。最後のオプションでは、スケジュールされたビルドを構成できます (図 4 を参照)。
.gif)
図 4 スケジュールに基づいてビルドを実行するための Team Build の構成 (クリックすると拡大画像が表示されます)
トリガは既定の [チェックインにより新しいビルドをトリガしない] に設定したままにし、[ビルドの既定値] オプションを選択する必要があります。ビルドの既定値を使用して、使用するビルド エージェントとビルド出力のドロップ場所を指定します。ドロップ場所は UNC パスを使用して指定します。マイクロソフトが提供している Virtual PC イメージを使用している場合は、「\\localhost\Drops\MSDNMag\SimpleBuildExplorer-OnDemand」と入力できます。共有のみ存在する必要があります。Team Build によって、必要に応じて追加のサブフォルダが作成されます。ビルド番号を使用して、このパスの下にフォルダが作成されます。
共有を作成する場合は、適切な権限を割り当てる必要があります。少なくとも、Team Build および TFS サービス アカウントには、共有に対する完全制御権が必要です。また、ビルドに関連するテスト結果を発行しようとしているユーザーには、書き込みアクセス許可を付与する必要があります。完成したビルドを取得する必要のあるユーザーには、読み取りアクセス許可を付与する必要があります。
共有を構成したら、ビルド エージェントを指定する必要があります。ビルド エージェントを既に定義してある場合は、コンボボックスから選択できます。定義していない場合は、[新規作成] ボタンをクリックすると、標準の [ビルド エージェントのプロパティ] ダイアログが開きます。この例では新規エージェントを定義する必要があるため、[新規作成] をクリックします。
ビルド エージェントを作成する
Team Build 2005 リリースとは異なり、Team Build 2008 のビルド エージェントはビルド定義に依存しません。エージェントを定義した後は、簡単に再使用できます。[ビルド エージェントのプロパティ] ダイアログで、エージェントに関連する重要なプロパティをすべて定義します。まず、表示名と説明 (省略可能) を入力します。次に、NETBIOS または DNS 名の形式でコンピュータ名を指定します。表示名とコンピュータ名はまったく別のものにすることができます。SSL を使用している場合は、そのオプションを指定できます。
重要な設定は作業ディレクトリです。既定では、$(Temp)\$(BuildDefinitionPath) の形式のパスを使用します。これは多くのビルドに対して動作しますが、MAX_PATH の問題が発生するおそれがあるため問題の原因となります。Windows Server 2003 マシンの $Temp は %SystemDrive%\Documents and Settings\<build agent service account>\Local Settings\Temp となります。これは、使用するには文字数が多すぎます。通常は、Database Professional ビルドをビルドする場合には特に、他のもっと短いパスに変更することをお勧めします。この例では、作業ディレクトリを C:\Builds\$(BuildDefinitionPath) に変更します。
最後に、エージェントのステータスを制御できます。この機能はサービスの提供に特に役立ちます。また、TFS はビルド エージェントと通信できない場合にエージェントのステータスを到達不可に変更して、管理者が設定を変更するまでエージェントを使用不能にします。設定を有効なままにして [OK] をクリックし、完了した [ビルド エージェントのプロパティ] ダイアログを閉じます (図 5 を参照)。[ビルド定義] ダイアログに戻ると、すべての警告三角形が消えており、[OK] をクリックしてビルドの定義を完了できます。
.gif)
図 5 完了した [ビルド エージェントのプロパティ] ダイアログ
チーム エクスプローラ ウィンドウの [ビルド] フォルダに、ビルド定義が表示されます。これを右クリックすると、直前に使用したのと同じ [ビルド定義] ダイアログに戻る [ビルド定義の編集] オプションが表示されています。また、[新しいビルドをキューに配置] オプションを使用して、新しいビルドをキュー登録できます。
Team Build 2005 とは異なり、Team Build 2008 では、ビルドのキュー登録がサポートされるようになりました。これは、マイクロソフトが継続的な統合を適切にサポートする場合に必要な機能でした。このオプションを選択すると、[ビルドをキューに配置] ダイアログが開き (図 6 を参照)、いくつかのオプションを調整できます。まず、必要に応じて既定のビルド エージェントを別のエージェントに簡単に変更できます。次に、ドロップ場所を調整できます。また、[キュー内の優先度] オプションを調整することで、特定のビルドに "キューをジャンプ" させることができます。最後に、ユーザーがビルドの管理アクセス許可を持っている場合は、MSBuild コマンドライン引数を渡すことができます。
.gif)
図 6 [ビルドをキューに配置] ダイアログ
チーム ビルドを実行する
[キュー] をクリックしてビルドを開始します。すると、更新されたビルド エクスプローラ ウィンドウが開きます。このウィンドウには 2 つの主要タブがあります。キュー登録済みのタブには、エージェントやステータスに関係なく、キューに配置されているすべてのビルドが既定で表示されます。ビルド定義、ビルドのステータス、またはビルド エージェントに基づいてビルド エクスプローラに表示されるビルドを調整するために使用できるコンボボックスが表示されます。
完了したタブでは、完成したビルドが表示され、同じ種類のフィルタ処理がサポートされます。ビルドを開始すると、ビルドをダブルクリックしてライブ ビルド レポートを表示できます。Team Build によって、ビルド プロセスの進行と共にこのレポートがリアル タイムで更新されます。
チーム ビルドを実行すると、いくつかのアクションが実行されます。TFS がキューからビルドを開始した後、ビルド エージェントはビルドを実行する準備が整います。TFS によってビルド番号が作成され、ビルド エージェントがソースをビルド定義で指定された場所と同期します。エージェントはコードをコンパイルし、必要に応じてコード分析を実行します。続いて、ビルド エージェントはテストを実行します。次に、ビルド番号に関連付けられた作業項目を更新するタスクがエージェントによって実行されます。
たとえば、MSF-Agile テンプレートの既定のタスク作業項目には、Team Build によって更新される [統合ビルド] フィールドがあります。エージェントはコード カバレッジを計算し (テストがビルドの一部として実行されるように構成され、コード カバレッジが有効になっている場合)、最後の正常なビルド (コンパイルが正常に終了) と現在のビルドの間のすべての変更セットを判断します。ファイルがドロップ共有にコピーされ、ビルド結果が TFS にパブリッシュされ、TFS によってビルド完了イベントが起動されます。TFS イベントの詳細については、筆者の
2008 年 5 月号のコラムを参照してください。
テストと作業項目に関連してマイクロソフトが Team Build 2008 で行った重要な変更が 2 つあります。最初の変更は、ビルドの 1 つ以上のテストが失敗してもビルドが失敗しないことです。代わりに、1 つ以上のテストに失敗したビルドは、Team Build 2005 のように [失敗] ではなく、[部分的に完了] として表示されます。次に、Team Build 2005 では、ビルドの初回実行時に、Team Build によって、チーム プロジェクトの開始以降の最初のビルド レポートに、ビルドされた項目に関連するすべての作業項目と変更セットが一覧表示されます。Team Build 2008 は、ビルドが初めて正常に実行された後でのみ、作業項目の表示と更新を開始します。筆者の次回のコラムでは、ビルドのカスタマイズによってこれらの動作を調整する方法を説明します。
Team Build をプログラミングする
Team Build 2008 で行われた大きな拡張の 1 つは、マネージ API の追加です。Microsoft.TeamFoundation.Build.Client.dll は、使用する主要アセンブリです。このコラムのサンプル アプリケーションでは、このアセンブリに加えて、Microsoft.TeamFoundation.Client.dll および Microsoft.TeamFoundation.VersionControl.Client.dll というアセンブリを参照しています。
サンプル アプリケーションは、新しい API の一部を検証する単純な Windows フォーム アプリケーションです。アプリケーションは、TFS に接続し、すべてのチーム プロジェクトの一覧を列挙して、それらをツリー ビュー コントロールに読み込みます。各チーム プロジェクトの下に、Build Agents ノードと Build Definitions ノードが追加されます (図 7 を参照)。
.gif)
図 7 サンプル アプリケーション (クリックすると拡大画像が表示されます)
ノードを展開すると、TreeNode の BeforeExpand イベントのコードが実行され、展開したノードに応じて使用可能なビルド エージェント、ビルド定義、または完成したビルドが列挙されます。また、メイン フォームには、Property Grid コントロールがホストされます。null 以外のタグ値を持つノードを選択すると、アプリケーションによって参照オブジェクトが Property Grid の SelectedObject プロパティに読み込まれます。図 7 に、MSDNMag チーム プロジェクトが展開され、Main Build Agent が選択されているアプリケーションを示します。
アプリケーションの大部分は単純な列挙コードです。ただし、マイクロソフトがチーム エクスプローラで公開しなかった機能が 1 つあります。ビルド エージェントを定義する場合、TFS はビルド エージェントのスコープを特定のチーム プロジェクトに設定します。一方、多くの組織には 1 つか 2 つのビルド エージェントしかないことがわかりました。このため、最終的にビルド エージェントを複数回再作成する必要があります。サンプル アプリケーションでビルド エージェント インスタンスを右クリックすると、コンテキスト メニューと [Copy Agent To] コマンドが表示されます (図 8 を参照)。
.gif)
図 8 [Copy Agent To] コマンド
このオプションを選択すると、ビルド エージェント定義のコピー先にするチーム プロジェクトを選択できるダイアログが開きます。該当するコードは、図 9 に示す CopyAgentToToolStripMenuItem_Click イベント ハンドラだけです。
図 9 CopyAgentToToolStripMenuItem_Click メソッド
Private Sub CopyAgentToToolStripMenuItem_Click( _
ByVal sender As System.Object, _
ByVal e As System.EventArgs) _
Handles CopyAgentToToolStripMenuItem.Click
Dim current As TreeNode = tv.SelectedNode
Dim ba As IBuildAgent = _
TryCast(current.Tag, IBuildAgent)
If ba Is Nothing Then Exit Sub
Dim parentProject As String = ba.TeamProject
Using frm As New frmPickProject
frm.cboProjects.DataSource = _
(From item In teamProjectNames _
Where item <> parentProject _
Select item).ToArray()
If frm.ShowDialog(Me) = Windows.Forms.DialogResult.OK Then
Dim teamProjectName As String = _
frm.cboProjects.SelectedItem.ToString()
Dim existingAgent = _
(From item As IBuildAgent In _
m_bs.QueryBuildAgents(teamProjectName) _
Where item.Name = ba.Name).SingleOrDefault
If existingAgent Is Nothing Then
Dim newBuildAgent As IBuildAgent = _
ba.CopyTo(teamProjectName)
newBuildAgent.Save()
MessageBox.Show(newBuildAgent.Name & " copied.")
Else
MessageBox.Show(existingAgent.Name & " already exists.")
End If
End If
End Using
End Sub
選択したノードに、IBuildAgent 参照に設定されたタグがあると想定した場合、コードでは frmPickProject フォームが表示されます。このフォームには、現在のビルド エージェントのチーム プロジェクトを除く、使用可能なすべてのチーム プロジェクトを表示するコンボボックスが含まれます。
コードでは、ツリー ビューのルートを初めて展開したときに収集されるすべてのチーム プロジェクト名の文字列配列に対して LINQ クエリを実行することで、コンボボックスのデータ ソースが設定されます。チーム プロジェクトを選択し、プロジェクト選択フォームで [OK] をクリックしたと想定した場合、コードでは LINQ クエリが実行され、ターゲット チーム プロジェクトにまだ同じ名前のビルド エージェントがないことが確認されます。同じ名前のエージェントが見つかった場合は、メッセージが表示されます。一方、見つからなかった場合は、ビルド エージェント定義がコピーされます。
特に興味深いことの 1 つは、マイクロソフトが CopyTo メソッドを提供していることです。筆者が最初にこのコードを考案したときは、新しい IBuildAgent インスタンスに対してプロパティごとのコピーを行うことを計画していました。マイクロソフトは API を追加し、ユーザー インターフェイスには追加しなかったようです。
Team Build 2008 が非常に強力なビルド製品であることをご理解いただけたならさいわいです。Team Build 2005 を使用している場合は、Team Build 2008 にアップグレードすることに大きな価値があります。筆者の次のコラムでは、ビルドのカスタマイズと、ビルドでソリューションをコンパイルするだけでなくテスト環境に配置する方法などについて掘り下げます。
このコラムの執筆に力を貸してくれた Ken Getz と Martin Woodward に感謝します。
Brian A. Randell は、MCW Technologies, LLC のシニア コンサルタントです。マイクロソフト テクノロジについての講演や執筆を行っています。Microsoft MVP として、Pluralsight 社の Applied Team System コースの作成にも携わりました。
mcwtech.com/cs/blogs/brianr にブログを公開しています。