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

サーバ・ビルドの注意点

　Visual StudioにNuGetのライブラリを追加している場合、クライアントでNuGetを更新しても、サーバ側では更新されない。だからといって、参照用のアセンブリまでTFSのリポジトリに登録すると、リポジトリがすぐに大きくなり、TFS Expressの上限の10Gbytesに到達してしまう。

　このような場合、（次の画面に示すように）ソリューションを右クリックして、［NuGetパッケージの復元の有効化］をクリックすると、TFSのソース管理対象から参照用アセンブリを外すことができる。

ソリューション・エクスプローラでNuGetパッケージの復元を有効化する

　［NuGetパッケージの復元の有効化］を選択すると、ソリューションの構成が一部変わり、ビルド・サービスがネットワークからNuGetパッケージを取得するようになる。もちろん、Proxyを使っている場合、ビルド・サービスを実行しているアカウントにProxyを設定していないと失敗するので気を付けてほしい。特にTFS Expressの初期実行アカウントであるLOCAL SERVICEでは、以下のコマンド例のようにして明示的にシステム・アカウントにProxyを登録した後、ビルド・サービスを再起動する必要がある。

　NuGetで使用しているパッケージは、しばしば更新される。サーバでNuGetの更新をしていたとしても、クライアントで依存関係を更新しない限り自動的にNuGetパッケージが更新されることはない。実際にやってみよう。

　まず、ソリューション・エクスプローラでソリューションを右クリックして、［ソリューションのNuGetパッケージの管理］を選択する。すると、以下に示す［XXX - NuGet パッケージの管理］ダイアログが表示される（XXXはソリューション・ファイルの名前。ここでは「MvcApplication1.sln」）。

　このダイアログの左側のペーンで［更新プログラム］からNuGetパッケージの入手先を指定するすると（通常は［NuGet 公式パッケージ ソース］でよいだろう）、現在のソリューションで更新可能なNuGetパッケージが表示される。原則、更新するパッケージの［更新］ボタンを1つずつクリックする必要がある。ただし、依存関係のあるものは複数同時に更新される。逆に更新されているライブラリであっても、依存関係の都合上更新できない場合もある。

NuGetパッケージの管理ダイアログ
NuGetで使用しているパッケージを1つずつ更新しているところ。
　 （1）NuGetパッケージの取得先を選択する。
　 （2）更新対象のNuGetパッケージが一覧表示される。
　 （3）更新処理を行うボタン。依存関係も自動的に判断される。
　 （4）パッケージの説明が表示される。

　また、コンテンツによってはNuGetパッケージの更新だけではなく、チェックイン済みのNuGetパッケージのファイルが削除されることがある。このような場合は、削除されたタイミングで、そのファイルをもう一度TFSにチェックインしておこう。これを行っておかないと、ソース・コードの依存関係の都合で、必要なはずのファイルがなくなったままになり、サーバ・ビルドが失敗することがある。ビルド定義の作成時に［トリガー］タブでチェックイン・トリガーに［継続的インテグレーション］を指定しておけば、チェックインのタイミングでサーバ・ビルドが実行される。

　自動ビルド時にテストも実行しておけば、依存関係の更新が行われるたびに所定のテストが自動的に行われるため、ライブラリに互換性がなかった場合でも低コストで発見できるためお勧めだ。

.NETアプリ以外のビルド

　本連載で見てきたとおり、TFSのビルド・サービスはVisual Studioのプロジェクト・ファイルに初期状態で最適化されているため、とても簡単に導入できる。しかもビルド定義の画面コピーで紹介したように、ビルド・サービスはWindows Workflowを使って記述されたビルド定義に従って実行される。このため、Windows Workflowで独自の処理を構築したうえで、ビルド・タスクから呼び出すことのできるアセンブリを登録すれば、ソリューション・ファイルのビルドに限らず、モジュールのデプロイやほかのWebサービスの呼び出しなども可能だ。

　余裕ができたらぜひ挑戦してほしい。

　次回は継続的インテグレーションで重要なデプロイの自動化や、TFSでの高度な連携機能について解説を行う。

「連載：いまどきのソース・コード管理」