Visual Studioでサーバ・ビルドを行うには、その前に「ビルド定義」を行う必要がある。ビルド定義ファイルはWindows Workflow用のXAML形式のファイルとなっている。ビルド定義は一から作ることもできるが、Team Foundation Serverにはチーム・プロジェクトを作った時点であらかじめいくつかのテンプレートが用意されているので、最初はこれを使えばよい。ビルド・プロセス・テンプレートはチーム・プロジェクトの「BuildProcessTemplete」フォルダに入っている(参考:「MSDN: カスタム ビルド プロセス テンプレートの作成と使用」)。
自分でビルド・プロセス・テンプレートを作った場合もこのフォルダに格納すればチーム・メンバーで共有できる。どんなビルド・プロセス・テンプレートがあるかは、[チーム エクスプローラー]タブの[ホーム]画面(これは家のアイコンをクリックすると表示される)で[ソース管理エクスプローラー]を選択すると表示される。
もちろんWindows WorkflowのXAMLなので、Visual Studioで開くこともできる。
ページの都合上、展開した状態は表示しないが、右上にある[すべて展開]ボタンをクリックすると、全ての処理が表示される。ビルド・プロセス・テンプレートでは多くの処理が定義されている。興味があればぜひ一度見てほしい。
ではサーバ・ビルドを行うためのビルド定義を作ってみよう。ここでは、前々回の手順でチーム・プロジェクトを作り、上記の構成とASP.NET MVC 4アプリケーションの作成を行って、TFSにチェックインしているものとする。
まず、(次の画面のように)[チーム エクスプローラー]タブの[ホーム]画面から[ビルド]をクリックする。
チーム・エクスプローラの[ビルド]をクリックすると、次に示すようなビルド定義画面に切り替わる。
上の画面では、定義済みのビルド定義の表示、自分が実行したビルドの結果などの管理ができる。ビルド定義を新規作成するには[ビルド定義の新規作成]リンクをクリックすると、Visual Studio内にビルド定義が新規作成される。ビルド定義名は現在のソリューションで作られているが、変更することも可能だ。次の画面は実際にビルド定義を新規作成しているところだ。
まず、ビルド・キューの定義を行う。通常は[有効]でよいが、状況によって[一時停止]や[無効]を使用する。ビルド定義名は重要だ。いちいち開かなくてもいいように、はっきり分かる名前を付けておこう。今回は継続的インテグレーション(Continuous Integration)を使用するため、「MvcApplication CI Build」という定義名にした。
次に、[トリガー]タブで、どんなタイミングでビルドを行うか、そのトリガの設定を行う。
次はビルド・トリガの選択を行う。ここで選択できる項目は注意して選ぶ必要がある。
トリガの種類 | 説明 |
---|---|
[手動](既定) | チェックインしてもビルドは実行されない。クライアントから明示的に指示する必要がある |
[継続的インテグレーション] | チェックインごとにビルドを実行する。ビルドが多く実行されていた場合はサーバに負担がかかることがあるが、依存関係やテストで問題があればすぐに検出できるため、可能な限りこれを選んでほしい |
[ビルドのロール] (Update 3では[ロール ビルド]) |
ビルドが実行されていない場合、そのままビルド・キューに格納され、順番にビルドが行われる。ビルドが実行中であった場合、後続のビルドはビルドが完了するまで待機する。最少ビルド間隔を設定することにより、ビルドを行う間隔を制限できる。 高頻度にチェックインが行われており、ビルド時間がかかる場合、ビルド完了が意図しない時間になることがある |
[ゲート チェックイン] | 変更点が正常にマージされ、正しくビルドできる場合のみチェックインされる。サーバ・ビルドは、そもそもサーバで全体をビルドすることにより早期に問題点を発見しようという開発手法だが、ゲート・チェックインはさらに一歩進んで、逆にビルドが完全になるまでチェックインさせないという考え方である。 大規模な環境でチェックイン済みのソース・コードは必ず生成可能なもののみ、という方式を使う場合、ゲートチェックインは非常に有用だ |
[スケジュール] | 指定した時間および間隔でビルドを行う。例えば、開発対象のソリューションが複数で大きくなり、日中のビルドが現実的な時間でできなくなった場合、ゲート・チェックインや継続的インテグレーションで行うビルドは一部のソリューションにとどめて、夜中のサーバが空いている時間で完全ビルドを行う、という開発サイクルを採用する場合に使用できる。 夜間にビルドが終わっていれば、翌朝からテスターは最新のビルドでテストを行うことができる |
トリガの設定が終わったら、次に[ソース設定]タブで、ソースのフォルダ関連設定を行う。
[ソース設定]タブではビルドの対象となるソース管理フォルダと出力フォルダを指定する。[ビルド エージェント フォルダー]の欄に「$(SourceDir)」と指定しているのはビルド・エージェントがTFSから取得して展開するための一時作業フォルダだ。容量の大きなドライブを指定しないとビルド中に失敗することがある。この指定はビルド・サーバ側で行う必要がある。ビルド・サーバ側での指定方法は後述する。
次に[ビルドの既定値]タブで、ビルド・コントローラとステージングの設定を行う。
ビルドに使用するビルド・コントローラおよび、ステージング(=正式環境に展開する前にテストするための環境)を行う位置を指定する。
次に[プロセス]タブでビルド関連の設定を行う。
ここでは、ビルド・プロセスに設定するパラメータを指定する。必ず指定しなくてはならないのは[必須]の下にあるソリューション・ファイル名とビルド構成だ。最初はここだけ指定して、慣れたらほかのところ、特にテストの設定をしてみよう。
最後に[アイテム保持ポリシー]タブで、ビルド結果の保持に関する設定を行う。
この画面では、ビルド結果をどのくらい保持しておくかを設定する。既定のテンプレートの初期値では成功も失敗も10ビルドまで保存する。ビルド保持数はディスク容量に直結するため、テストとビルド頻度で保持数を調整する必要がある。ビルドの対象となるソリューションが全てサーバ側に格納されるため、クライアントで一度同じビルドを行い、フォルダ容量を計算しておけば、一度のビルドでどの程度のディスク容量を使用するかあらかじめ見積もることもできる。
以上の設定を行い保存すると、ビルド定義が作成され[すべてのビルド定義]に表示されるようになる(次の画面を参照)。
Copyright© Digital Advantage Corp. All Rights Reserved.