Team Foundation Server

Visual Studio TFS のチーム プロジェクトとコレクションのガイド

Willy-Peter Schaub および Mike Schimmel

MSDN マガジンの記事「Visual Studio TFS での分岐とマージのガイド」(msdn.microsoft.com/magazine/gg598921) では、Visual Studio ALM Rangers が、ソリューションとアプリケーション ライフサイクル管理 (ALM) プロセス全体の一貫性および品質を向上するため、たくさんの新しい分岐シナリオと関連ガイダンスを紹介し、実際の分岐とマージの複雑な環境における作業を支援しました。

前回の記事でも触れましたが、Rangers は、不足している機能に対処し、導入を妨げるものを取り除きながら、Visual Studio 製品グループ、Microsoft サービス、および Microsoft Most Valuable Professional (MVP) コミュニティの間の連携を推し進める専門家グループです。

今回の記事では、この Rangers が、Team Foundation Server (TFS) のチーム プロジェクトおよびチーム プロジェクト コレクションの編成とプロビジョニングのガイドを提供します。

今回は、次の内容についての理解を深めます。

• チーム プロジェクト コレクションとそのメリット
• 1 つまたは複数のチーム プロジェクトを組み合わせて 1 つのチーム プロジェクト コレクションにするか、1 つまたは複数のチーム プロジェクトをそれぞれ個別のチーム プロジェクト コレクションで管理するかを選択する場合の考慮事項
• チーム プロジェクトとチーム プロジェクト コレクションを編成して、分離レベルを高めたりスケーラビリティを向上したりするうえでの考慮事項
• 1 つまたは複数の非アクティブなチーム プロジェクトをアーカイブに保管する方法

今回は、チーム プロジェクトとチーム プロジェクト コレクションの編成が、次のような課題によってどのような影響を受けるかを、課題別に理解します。

• TFS、チーム プロジェクト コレクション、およびチーム プロジェクトのセキュリティとプロビジョニング
• プロセス テンプレートの選択
• プロセス テンプレートのカスタマイズ (カスタマイズされたワークフロー、作業項目の種類のカスタマイズ、カスタム レポート、カスタム クエリ、カスタマイズされたプロセス ガイダンスなど)
• チーム編成
• チーム プロジェクト編成 (区分、イテレーションなど)
• プロジェクト管理の考慮事項 (プロジェクトのマイルストーン、スケジュールなど)

計画

Visual Studio TFS を計画する場合、通常、すべての関係者にとって効果が高くかつ拡張可能な ALM システムにするため、チーム プロジェクトとチーム プロジェクト コレクションの推奨インフラストラクチャとその構造を決めることから着手します。

Rangers のガイダンス プロジェクトの Visual Studio 2010 クイック リファレンス ガイダンス (vs2010quickref.codeplex.com、英語)、および Visual Studio 2010 と TFS 2010 の仮想マシン (VM) ファクトリ (rangersvsvmfactory.codeplex.com、英語) では、容量計画のサポートと、物理インフラストラクチャと仮想インフラストラクチャの選択を支援する、概念、ガイダンス、およびクイック リファレンスを提供しています。

通常、TFS 2010 の環境では、チーム プロジェクトの前にチーム プロジェクト コレクションを計画および定義しますが、ここでは最初にチーム プロジェクトについて説明します。

Visual Studio チーム プロジェクト

TFS 2005 および TFS 2008 では、1 つの TFS Server で 1 つまたは複数のチーム プロジェクトをホストできます。各チーム プロジェクトとは、基本的にはプロジェクトの成果物のコンテナーです。プロジェクトの成果物には、ソース コード (フォルダー、分岐したフォルダー、および分岐に編成される)、1 つまたは複数の Visual Studio ソリューション (ソース コードのコンテナー)、チーム ビルドの構成ファイル、チームのロード テスト エージェント、任意の SharePoint リポジトリ (プロジェクトの関連ドキュメントを含む)、セキュリティのプロビジョニング (プロセス テンプレートで制御される一連の作業をチームで追跡および実行する際に使用) などがあります。チーム プロジェクトを、Visual Studio .NET プロジェクト (Microsoft .NET Framework アセンブリの生成に必要なすべてのビルドと構成の設定を含む)、Visual Studio .NET ソリューション (1 つまたは複数の Visual Studio .NET プロジェクトを含み、プロジェクトの依存関係、ビルド プロセス、およびビルド順序を定義する)、またはプロジェクト イニシアチブ (一連の要件からビルドを実行するためにスケジュールされたイニシアチブ) と混同しないようにしてください。

チーム プロジェクトの作成および管理の詳細については、MSDN ライブラリの「チーム プロジェクトの作成および管理」(msdn.microsoft.com/ja-jp/library/ms243128(v=VS.80)) を参照してください。

では、複数のプロジェクト イニシアチブをチーム プロジェクトに編成する際の考慮事項について説明します。チーム プロジェクトは、多くの場合、1 つの製品または 1 つの製品ラインの開発に関連する、最も大きな作業単位を含みます。マイクロソフトを例に挙げると、Visual Studio と Office は、それぞれ個別のチーム プロジェクトに含まれる 2 つの製品ラインです (図 1 参照)。これらの 2 つの製品ラインの開発は、個別のマイルストーンとリリース スケジュールに基づき、まったく異なるタイムラインで行われます。

図 1 Visual Studio チーム プロジェクトと Office チーム プロジェクト

プロビジョニングの考慮事項とセキュリティの分離については、重要なので注意してください。新しいチーム プロジェクトを作成する際に最も時間がかかる作業の 1 つが、1 つまたは複数のチームから使用できるようにプロジェクトをプロビジョニングするために必要な作業です。このプロビジョニングでは、主に、チーム プロジェクトとその成果物へのアクセスを制御する、セキュリティ ユーザー、グループ、および権限を定義します。ここでは、チームのメンバーが必要な処理を実行できるように、適切な細かさでセキュリティを定義することで得られるメリットと、そのためにプロビジョニングを行う作業の負荷のバランスを取る必要があります。セキュリティを適切にプロビジョニングできれば、特定のタスクを実行することを想定されていないメンバーによる不測または故意の損傷から、チーム プロジェクトとその資産を保護することができます。

Visual Studio と Office など、マイルストーンやリリース スケジュールが異なる製品ラインでは、セキュリティの分離を目的として、各製品ラインを個別のチーム プロジェクトに編成するのが理にかなっています。各製品ラインに関連する開発チームは、完全に独立している可能性が高く、両方のチーム環境の操作やビルド権限を要求したり付与したりすることはほとんどありません。

異なる方式論のプロジェクト イニシアチブ (たとえば、1 つのチームでは Microsoft Solutions Framework (MSF) for Agile Software Development バージョン 5.0 プロセス テンプレートを使用し、もう 1 つのチームでは MSF for CMMI Process Improvement バージョン 5.0 プロセス テンプレートを使用する場合など) では、1 つのチーム プロジェクトで関連するプロセス テンプレートを 1 つしか使用できないため、個別のチーム プロジェクトが必要です。

区分およびイテレーションを一意に定義する必要があるプロジェクト イニシアチブでは、1 つのチーム プロジェクトで区分およびイテレーションの 1 つの階層を定義するため、個別のチーム プロジェクトを使用することをお勧めします。また、1 つのチーム プロジェクトでは、区分を使用して複数の機能チーム (図 2 参照) を編成し、その機能チームで同じイテレーション (図 3 参照) を共有することができます。たくさんの小規模チーム プロジェクトの代わりに区分を使用するシナリオの詳細については、Martin Hinshelwood のブログ記事「Team Foundation Server 2010 を使用したプロジェクトのプロジェクト」 (bit.ly/hSnHGw、英語) を参照してください。

図 2 区分を使用して個別の機能チームを編成するチーム プロジェクト

図 3 イテレーション階層を共有する複数の機能チームを含むチーム プロジェクト

バージョン管理のチェックアウト設定 (排他チェックアウト、チェックイン ポリシー、チェックイン メモなど) は、1 つのチーム プロジェクトに対して定義し、複数のチーム プロジェクトにまたがって共有することはありません。各プロジェクト イニシアチブで異なるソース管理設定が必要であれば、これらの設定は個別のチーム プロジェクトに関連付けなければなりません。

プロセス テンプレートのカスタマイズには、カスタマイズされたワークフロー、カスタム ワークフロー、作業項目の種類 (WIT)、レポート、およびクエリが含まれます。新しいチーム プロジェクトの作成に使用するプロセス テンプレートをカスタマイズしたり、1 つのチーム プロジェクトで使用する特定のプロセス テンプレートをカスタマイズしたりできますが、後者のプロセス テンプレートはチーム プロジェクト間では共有されません。

チーム プロジェクトの成果物の共有は、通常、あるチーム プロジェクトから別のチーム プロジェクトに分岐することで実現されます。前回の記事では、共通コードを共有するためのさまざまな手法について説明しましたが、その大半の手法で分岐を使用しました。

おわかりのように、個別のプロジェクトやプロジェクト イニシアチブで、同じチーム プロジェクトを共有するか、個別のチーム プロジェクトに関連付ける必要があるかどうかを判断するため、たくさんの考慮事項があります。さまざまな考慮事項について理解し、組織にとって最適なチーム プロジェクト編成を決定する必要があります。

Visual Studio チーム プロジェクト コレクション

チーム プロジェクトは互いにある程度独立しているにもかかわらず、TFS 2005 および TFS 2008 では、複数の TFS Server を 1 台のサーバーに統合するなどの特定のメンテナンス作業が困難でした。さらに、組織内の各部署で分離を実現するには、組織に 2 台以上の TFS Server を実装し、インフラストラクチャ、メンテナンス、および全体的な複雑さにかかるコストを増やすしかありませんでした。

Visual Studio 2010 では、チーム プロジェクト コレクションが導入されます。各 TFS Server は、1 つまたは複数のチーム プロジェクト コレクションを保持できます。さらに、チーム プロジェクト コレクションが 1 つまたは複数のチーム プロジェクトを保持します。チーム プロジェクト コレクションは、TFS の回復の基本単位です。バックアップと復元の観点から見ると、チーム プロジェクト コレクションは SharePoint サイト コレクションに似ています。

Visual Studio 2010 クイック リファレンス ガイダンス プロジェクト (vs2010quickref.codeplex.com、英語) では、新しいチーム プロジェクト コレクションの機能とチーム プロジェクトの計画を支援する、クイック リファレンスを提供しています。チーム プロジェクト コレクションでは、よりスケーラビリティの高い TFS Server の展開を提供します。TFS 2010 の 1 つのチーム プロジェクト コレクションは、TFS 2005 または TFS 2008 での 1 つの TFS Server にほぼ相当します。チーム プロジェクト コレクションの作成および管理の詳細については、msdn.microsoft.com\library\dd236915 を参照してください。

複数のチーム プロジェクトを個別のチーム プロジェクト コレクションに分離する際は、スケーラビリティ、バックアップ、回復、セキュリティの分離、チーム プロジェクト間の情報共有などを考慮する必要があります。

TFS Server のスケーラビリティは、物理 SQL Server と SQL Server インスタンスにチーム プロジェクト コレクションの負荷を分散する機能によってサポートされており、通常はデータベース環境に関連付けられるスケーラビリティと負荷分散のインフラストラクチャを利用します。複数の SQL Server に負荷を分散できる場合は、複数のチーム プロジェクト コレクションにチーム プロジェクトを分割することでメリットを得られる可能性があります。

既に説明したように、TFS の回復の基本単位はチーム プロジェクト コレクションです。チーム プロジェクトは、個別にバックアップを行ったり、復元したりすることはできません。細かい単位でのバックアップや回復の機能が必要な場合 (たとえば、チーム プロジェクトを 1 つだけ回復する必要がある場合など)、バックアップや回復を目的として、チーム プロジェクトを個別のチーム プロジェクト コレクションに分離することで、メリットを得られる可能性があります。

チーム プロジェクト コレクションのセキュリティのプロビジョニングは、適切なレベルの制御と細かさで管理しようとすると、時間がかかる可能性があります。新しいチーム プロジェクト コレクションを追加するときには、これらのコレクションをそれぞれプロビジョニングするために最初に行う作業と、プロジェクトの運営中に行う作業について検討しておく必要があります。TFS Server で管理されているチーム プロジェクトにかかわるプロジェクト チームに、異なるセキュリティ上の要件が設定されている場合は、セキュリティ保護を目的として、チーム プロジェクトを個別のチーム プロジェクト コレクションに分離するとメリットを得られる可能性があります。

一方、TFS Server で管理されているチーム プロジェクトにかかわるプロジェクト チームで、セキュリティの分離が必要なければ、同じチーム プロジェクト コレクション内にチーム プロジェクトを含めるとメリットを得られる可能性があります (図 4 参照)。

図 4 チーム プロジェクト コレクションの共有と分離の境界

成果物 (ソース コード ファイルなど) は、同じチーム プロジェクト コレクションのチーム プロジェクト間で共有できますが、コレクションをまたがって共有することはできません (図 4 参照)。2 つのチーム プロジェクトで成果物を共有する必要がある場合、これらのチーム プロジェクトは同じチーム プロジェクト コレクションに含める必要があります。

チーム プロジェクト コレクションを使用したソース コードの共有と分離、および分岐とマージについては、今回は取り上げません。関連情報については、tfsbranchingguideiii.codeplex.com (英語) を参照することをお勧めします (この情報については、今後のガイダンスで紹介する予定です)。

チーム プロジェクトのアーカイブ方針

TFS 環境を限られた物理リソースにしかインストールできない場合、定期的なメンテナンスが不可欠です。管理者は定期的なメンテナンスを計画して、プロジェクト データが開発チームにとってパフォーマンス上の問題とならないように、完全にアーカイブし、サーバーの負荷を軽減する必要があります。

Rangers が提供するアップグレード ガイダンス vs2010upgradeguide.codeplex.com、英語) では、アップグレード ガイダンスの一部として使用できる、たくさんの方針を定義しています。これは、Microsoft Consulting Services が考案した、次の手順に似ています (図 5 参照)。

図 5 アーカイブ方針の例

1. まず、チーム プロジェクト コレクションのコピーを作成します。
2. 新しく複製したアーカイブ用のチーム プロジェクト コレクションから、アクティブなチーム プロジェクトを削除します (TFSDeleteProject コマンド ライン ユーティリティを使用します)。
3. 元の (アクティブな) チーム プロジェクト コレクションから、アーカイブ済みのプロジェクトを削除します。
4. 新しいチーム プロジェクト コレクションは、外部メディア (テープ、フラッシュ メディアなど) に格納してから、ハードウェアから削除します。監査をシステムで行う場合は、監査のためにアーカイブ メディアを簡単に復元できます。
5. 後で再び簡単に取得できるように、新しいチーム プロジェクト コレクションをデタッチします。

これは概念的には簡単な方針のように見えますが、実際には、アーカイブできるチーム プロジェクトとアーカイブできないチーム プロジェクトを特定するためのポリシーが必要になります。TFSDeleteProject コマンドによる操作を実行すると、ソース コードの分岐がシステムから削除されることには特に注意してください。これは元に戻す操作を実行できないイベントです。

アーカイブ ポリシーの例を次に示します。

• 開発チームがプロジェクト データのクリーンアップを行い格納できるように、プロジェクト終了ポリシーを確立します。ソース コードの他にも保存する必要があるマテリアルがあります。プロジェクトの要件に関心があっても、再利用したり、強化したりできる形式ではない可能性があります。機能仕様は、プロジェクトが完了して運用環境に移行する際、製品の状態が反映されるように、以前の仕様と統合する必要があります。これで、このプロジェクトの要件は、データを損失することなくアーカイブできます。作業項目は、ソース コードのように、あるチーム プロジェクトから別のチーム プロジェクトにマージすることはできません。そのため、プロジェクトの完了後に、完了した作業項目の格納方法を決定する必要があります。
• すべてのチームに、イベントより先に保留中のアーカイブ関連の操作を通知したり、アーカイブ対象となるすべてのチーム プロジェクトを一覧表示したりする、標準の要求を送信します。
• 各チーム プロジェクトに、完了したプロジェクト イニシアチブの最終プロジェクト データ (要件の一覧、最終プロジェクト レポート、通常のプロジェクト終了の方法論ポリシーに基づいて格納されるドキュメントなど) のコンテナーとして使用する、マイルストーン フォルダーを確立します。

アーカイブを正しく完了するには、基本的に、ソース コードだけでなく、すべてのプロジェクト データを保存する必要があります。

部署は 2 つ以上のマネージ エンティティに分離される可能性があるため、チーム プロジェクト コレクションを分割する必要があります。このシナリオでは、チーム プロジェクトをアーカイブしないにもかかわらず、チーム プロジェクトをアーカイブする際に使用するのと同様の手法を使用します。2 つ目のチーム プロジェクト コレクションは、元のチーム プロジェクト コレクションとは別に定期的なメンテナンスが必要になるため、元のチーム プロジェクト コレクションと同じように扱う必要があります。

チーム プロジェクト コレクション間でチーム プロジェクトを移動するのは簡単ではありません。また、コレクションを一度分割すると、マージし直そうとしても、新しいチーム プロジェクトがコレクションに追加されるだけなので簡単にはできません。チーム プロジェクト コレクションをマージするには、TFS API を使用して、あるコレクションから別のコレクションにプロジェクト データをコピーするカスタム コードが必要になります。

お勧めはしませんが、TFS Integration Tools を使用して、チーム プロジェクトをチーム プロジェクト コレクションにマージできます。詳細については、TFS Integration Tools のドキュメント (bit.ly/9tHWdG、英語) を参照してください。

今後の記事では、Rangers が、Visual Studio ALM ツールを使用して、アジャイル チームの分散管理の課題をどのように解決および対応しているかについて調査する予定です。

WillyPeter Schaub は、Microsoft Canada Development Center で、Visual Studio ALM Rangers のシニア プログラム マネージャーを務めています。80 年代中ごろから、ソフトウェア エンジニアリングにおける簡潔さと保守性を追求し続けています。彼のブログは blogs.msdn.com/b/willy-peter_schaub (英語) で公開されており、Twitter (twitter.com/wpschaub、英語) でフォローすることができます。

Mike Schimmel は、Microsoft Consulting Services (米国) の ALM ソリューション アーキテクトを務めており、Visual Studio ALM Rangers の主要メンバーです。25 年近くもの間、調査とコンサルティングから競合製品の販売やサービス提供に至るまで、ALM の分析と実践に携わってきました。

この記事のレビューに協力してくれた技術スタッフの Bill Essary、Bill Heys、Martin Hinshelwood、Bijan Javidi、および Mario Rodriguez に心より感謝いたします。