Team Foundation ビルド システムについて

Team Foundation ビルドを使用して、自動化された分散システムでソフトウェアをコンパイル、テスト、および配置できます。 このソフトウェアは、小規模なソフトウェア開発の立ち上げだけでなく、成熟したソフトウェア開発エンタープライズにも活用できるように設計されています。 また、システムの設計として、チームとコード ベースの拡大に合わせてビルド システムを拡張できるようになっています。

このトピックの内容

• ビルド コンピューター

  • Team Foundation ビルド サービス

  • 仮想マシンのビルド コンピューターとしての使用

• ビルド コントローラー

• ビルド エージェント

• ビルド システム トポロジの例

• 次の手順

ビルド コンピューター

Team Foundation ビルドを使用するには、少なくとも 1 台のビルド コンピューターが必要です。 中規模から大規模なソフトウェア開発の場合、複数のビルド コンピューターが必要になる場合があります。 このトピックの後半では、ビルド システム構成の例をいくつか紹介しています。

ビルド コンピューターとは、Team Foundation ビルド サービス をインストールして構成したコンピューターのことです。 このコンピューターとして、物理マシン (机の下にあるパーソナル コンピューターやラボにあるワークステーションなど) を使用できます。 または、仮想マシンの柔軟性を利用して、これをビルド コンピューターとして使用することもできます。

ビルド コンピューターは、Team Foundation ビルド サービスが実行されているコンピューター上で直接構成、変更、および管理できますが、構成データ自体はチーム プロジェクト コレクションに格納されます。

Team Foundation ビルド サービス

ビルド コンピューターを設定するには、Team Foundation ビルド サービスをインストールして、構成し、実行します。

Team Foundation ビルド サービスは、オペレーティング システム内の異なる場所の一覧に表示される Windows サービスです。 一覧表示される場所は、Team Foundation ビルド サービスが Windows サービスとして実行されているか、対話型サービスとして実行されているかによって異なります (このオプションの設定方法の詳細については、「ビルド コンピューターの構成」を参照してください)。

Team Foundation ビルド サービスが Windows サービスとして実行されている場合:

• [サービス] ノードで、Team Foundation ビルド サービスは [Visual Studio Team Foundation ビルド サービス ホスト] として表示されます。 [サービス] ノードは、次のいずれかの場所で確認できます。

  • サーバー オペレーティング システム (Windows Server 2008 など) のサーバー マネージャー。

  • クライアント オペレーティング システム (Windows Vista など) のコンピューターの管理。

• タスク マネージャーで、Team Foundation ビルド サービス は [サービス] タブの一覧に [Visual Studio Team Foundation ビルド サービス ホスト] として表示されます。

Team Foundation ビルド サービスが対話型サービスとして実行されている場合:

• タスク マネージャーで、Team Foundation ビルド サービスは [アプリケーション] タブの一覧に [TFSBuildServiceHost] として表示されます。

仮想マシンのビルド コンピューターとしての使用

Team Foundation ビルド サービスは、仮想マシン (Windows Server 2008 が実行されている物理マシン上で稼動する Hyper-V 仮想マシンなど) にも配置できます。 この方法を実施すると、次のタスクを簡単に実行できます。

• システムを任意の時点の任意の状態でリビルドする。 たとえば、システムが破損した場合でも、問題のない環境のスナップショットにすぐに戻してシステムをリビルドできます。

• 仮想マシンのスナップショットを取得してエクスポートし、アーカイブしたりチームの他のメンバーと共有したりする。

仮想マシンをビルド コンピューターとして使用する場合の最大の欠点は、物理マシンよりも動作が遅いことです。 ビルドに必要な作業量が少ない場合や、ビルドの頻度が低い場合 (夜間に実行する場合など) であれば、仮想マシンでもシステムのビルド コンピューターとして十分に通用する可能性があります。

次のタスクを実行すると、Team Foundation ビルド サービスを仮想マシンで実行するときにパフォーマンスを向上させることができます。

• マルチコア プロセッサを搭載した物理マシン上で仮想マシンを実行する。 たとえば、物理マシンにクアッドコア プロセッサが搭載されていれば、同時に 4 つの仮想マシンを実行でき、多くの場合、それぞれがビルド コンピューターとして十分なパフォーマンスで動作します。

• 仮想マシンごとに専用の物理ハード ディスクを用意してマウントする。

ビルド コントローラー

各ビルド コントローラーは、1 つのチーム プロジェクト コレクション専用です。 コントローラーは、指定されたチーム プロジェクト コレクション内の任意のチーム プロジェクトからのビルド要求に応じます。

各ビルド コントローラーでは、1 つ以上のビルド エージェントのサービスがプールされて管理されます。 プロセッサ集中型の処理 (コードのコンパイルやテストの実行など) は、プール内のビルド エージェントに分散されます。

ビルド コントローラーは、ワークフローを処理し、ビルド名の決定、バージョン コントロールのラベルの作成、メモの記録、ビルドからのステータス レポートの作成など、主に軽量の処理を実行します。

通常、ビルド コントローラーはプロセッサ時間を大量に必要としないため、ビルド コントローラーのプラットフォームは仮想マシンでも十分な場合がよくあります。 ただし、特定の状況では、ビルド コントローラーで大量のメモリが必要になることがあります。 このため、ビルド コントローラーをセットアップする物理マシンまたは仮想マシンには、十分なメモリを用意する必要があります。

ビルド エージェント

各ビルド エージェントは、1 つのビルド コントローラー専用になり、そのコントローラーによって制御されます。 プロセッサ集中型およびディスク集中型の処理は、ビルド エージェントが行います。 この処理には、バージョン管理からのファイルの取得とチェックイン、ワークスペースのプロビジョニング、コードのコンパイル、およびテストの実行が含まれます。

ビルド システムをアセンブルするときは、少数のエージェントで始めることができます。 その後、チーム メンバーの追加やコード ベースの拡大、ビルド システムに要求される作業量の増加に合わせて、ビルド エージェントを追加してビルド システムを拡張できます。

エージェントに特殊な機能を持たせる場合は、それらのエージェントにタグを割り当てる必要があります。 この方法に従うと、これらの特殊なエージェントを使用できるビルド定義を作成できます。 たとえば、BVT テストを実行するように設計されたエージェントのプールには、BVT タグを適用できます。 その後で、これらのビルド エージェントのみを使用する夜間ビルドを定義することができます。

プロセッサ集中型の処理のほとんどはビルド エージェントによって実行されるため、ビルド コンピューターには、ビルド エージェントが許容時間内に処理を実行できるだけの十分な能力のあるハードウェアが必要です。

ビルド システム トポロジの例

Team Foundation ビルド サービスは、小規模で複雑でないビルド システムから始めることができるように設計されています。 その後のコード ベースの拡大やチーム メンバーの増加に合わせて、ビルド コンピューターを既存のシステムに徐々に追加することで、システムを比較的簡単に拡張できます。

単一コンピューターのシステム (アプリケーション層で共有)

以下の構成では、ごく小規模なチームがサポートされます。特に、ビルド頻度が低く、休業時間帯にしかビルドを実施しないチームを想定しています (たとえば、夜間に 1 回だけビルドを実行するような場合です)。

ほとんどの場合、単一のビルド コンピューターに関するトポロジは、次の理由から十分ではありません。

• ビルド エージェントによってプロセッサに高い負荷がかかるため、アプリケーション層のパフォーマンスが大幅に低下する可能性があります。

• ビルド コントローラーによって、システムのメモリに高い負荷がかかることがあります。これは特に、コントローラーが複数のアクティブなビルド エージェントを同時に管理している場合に当てはまります。

• Team Foundation ビルド サービスをインストールすると、ビルド コンピューターが攻撃を受ける可能性が増大します。 たとえば、悪意のあるユーザーがビルド定義を構築し、任意のコードを実行してサーバーの乗っ取りやデータの窃盗を企てる可能性があります。

単一コンピューターのシステム (スタンドアロン)

以下の構成は、小規模なチームの開始点として適しています。

ビルド エージェントは別個のコンピューターでプロセッサ集中型の処理を行うため、ビルドが実行されてもアプリケーション層のパフォーマンスには影響がありません。

専用のビルド コンピューターでビルド コントローラーを実行することもできます。 ただし、図に示す構成には、ビルド コンピューターの修復や交換が必要になった場合などに、ビルド システムの変更による悪影響を抑制できるという利点があります。

ビルド コントローラーをアプリケーション層と同じコンピューター上に配置しても、プロセッサの観点からは一般に問題になりません。 ただし、次の理由から、より拡張性の高いトポロジにグレードアップした方がよい場合があります。

• ビルド コントローラーによって、システムのメモリに高い負荷がかかることがあります。これは特に、コントローラーが複数のアクティブなビルド エージェントを同時に管理している場合に当てはまります。

• Team Foundation ビルド サービスをインストールすると、ビルド コンピューターが攻撃を受ける可能性が増大します。 たとえば、悪意のあるユーザーがビルド定義を構築し、任意のコードを実行してサーバーの乗っ取りやデータの窃盗を企てる可能性があります。

複数コンピューターのシステム

一般に、中規模から大規模のチームでは、開発作業をサポートするために複数のビルド コンピューターが必要になります。 次の例では、2 つのビルド コンピューターが配置されています。

複数のビルド コンピューターを使用すると、次の例に示すように、それぞれのコンピューターを別々の用途に割り当てることができます。

• 1 台のビルド コンピューターを、継続的な統合ビルドを処理するビルド エージェントの専用にすることができます。 チームでは、このような種類のビルド (特にゲート チェックイン ビルド) をすばやく実行し、ビルド待ちのために作業が滞ることがないようにする必要があります。 ビルドがすばやく実行されることを保証するために、ビルド処理のパラメーター設定を使用できます。 このような設定として、ワークスペースを消去しない設定、最も優先順位の高いテストのみを実行する設定、[最大実行時間] の値を小さくする設定などがあります。

• 別のビルド コンピューターを用意して、処理に時間のかかる、スケジュール設定されたビルドや臨時のビルド専用にします。 たとえば、このコンピューター上のビルド エージェントを対象とするビルド定義を設定し、その定義によってワークスペースを消去して、すべてのテストを実行し、コード分析を行うことができます。

複数のコントローラーがある複数コンピューターのシステム

以下のトポロジの例では、エンタープライズ レベルのソフトウェア開発をサポートできます。

各チーム プロジェクト コレクションには、図に示すように専用のビルド コントローラーが必要です。 このトポロジでのビルド コンピューターの分離方法に注目してください。 チーム プロジェクト コレクション A で作業するチーム メンバーは、ビルド コントローラー A によって制御されるビルド エージェントのみを使用できます。

次の手順

これで Team Foundation ビルド システムの動作を理解できたので、以下に示す次の段階に進むことができます。

• ビルド システムの設定

• ビルド システムの管理