第4回 TFSにおける自動ビルドの実践活用ポイント：連載：いまどきのソース・コード管理（1/2 ページ）

[亀川和史，著]

powered by Insider.NET

連載目次

　Team Foundation Server（以下、TFS）および、Team Foundation Service（以下、TF Service）では自動ビルドを実現するビルド・サーバ機能が統合されている。前々回はTFS Expressにビルド・サービスを構成して自動ビルド環境を完了させ、前回はそのVisual Studioから自動ビルドを定義して実際に実施する方法を説明した。

　今回は前々回から続く自動ビルドの説明のまとめとして、「作業項目との連携とビルド失敗の原因の調査」「サーバ・ビルドの注意点」「.NETアプリ以外のビルド」などTFSを実際に活用していくうえでのポイントや注意点を説明する。

作業項目との連携とビルド失敗の原因の調査

　サーバ・ビルドが成功すればいいが、失敗した場合はどうなるだろうか？ 第3回でもビルドが失敗しているので、ここでなぜ失敗したかを調べてみよう。

　チーム・エクスプローラの［マイ ビルド］にあるビルド結果を右クリックして、（表示されるコンテキスト・メニューから）［開く］をクリックすれば、次のようにビルド結果が表示される。

ビルド結果の表示
なぜビルドが失敗したかを調べているところ。
　 （1）ログ・ファイルの表示。
　 （2）サーバの格納フォルダを表示する。
　 （3）診断メニューを表示する。
　 （4）ビルドの品質を選択する。
　 （5）ビルド結果に対する動作を選択する。ブラウザで開く、削除、自動削除されないように保護する、再試行、ビルド定義の編集を行える。

　下方にスクロールするとビルド・エラーの原因が表示される。

ビルド・エラーのログ

　エラーが発生すると、担当者（＝通常は、ビルド・キューに投入したユーザー）の作業項目にビルドが失敗したことが自動的に登録される。（メニューバーの）［チーム］メニューの［新しいクエリ］を選択すると、登録されている作業項目（次の画面）が表示される。

プロジェクト内の全作業項目を表示するクエリ

　このクエリでは、失敗が増えるにつれて表示される項目も多くなるので、次のようなクエリ（具体的には［状態］＝「新規」と、［担当者］＝「@Me」を指定）を作ってチーム・クエリに保存しておけば、ビルド失敗の作業項目（自分が担当する新規のもの）がすぐに表示されるようになり便利だ。

プロジェクト内の自分に新しく割り当てられた作業項目を表示するクエリ

　なお、上のクエリでは、作業項目のリストに［単純なリスト (既定)］を選択しているが、ほかの作業項目を使うと、より高度なクエリを作成できるので、慣れてきたら挑戦してほしい。

　では、実際にビルド・エラーで登録された作業項目の詳細を見てみよう。

ビルドが失敗した場合に登録される作業項目の詳細

　ビルドに失敗したときには、担当者の作業項目として、このように登録される。担当者は原則、ビルドをキューに投入した人となるが、作業上の都合で変更したい場合は［担当者］欄からほかの登録メンバーに変更できる。TFSの管理コンソールでメールの設定を行っていれば、作業項目として登録されたタイミングで対象者にメールが送信される。では、実際にこのエラーを直してみよう。

　最初に原因を述べておくと、今回のエラーはASP.NET MVCプロジェクト・ファイルの中で使用しているビルド・タスクが使用しているアセンブリがTFS側にないのが原因で発生した。実際にTFSとVisual StudioのMsbuildフォルダ（c:\Program Files\Msbuild\Microsoft\VisualStudio\11.0）配下を比べて見たのが次の画面だ。かなり違いがあることが分かる。

TFSのMSBuildフォルダ配下のフォルダ／ファイル構成

Visual StudioのMSBuildフォルダ配下のフォルダ／ファイル構成

　一目で、かなりの違いがあることが分かるだろう。今回のエラーはTFS側にASP.NET MVC 4関係のビルド・タスクで使用しているアセンブリがないので、クライアントのVisual StudioからWebApplicationフォルダをTFSの同じフォルダにコピーすれば簡単に解決できる。ASP.NET MVCプロジェクト以外でもビルド・タスクで失敗しているプロジェクトがあれば、クライアントとTFSサーバのフォルダやファイルの内容に相違がないかを確認してみよう。また、出力先の共有ディレクトリのアクセス権限が原因でエラーが発生することもある。