バックグラウンド
Visual Studio ALM Rangers によると、TFS 2012 でリソース (多くの個別の製品で使用される共通ライブラリなど) を共有するには、主に 2 つの方法があります。
- ワークスペース マッピング、必要な各ライブラリと製品の適切なバージョンを指すようにワークスペースを設定します。
- 共有フォルダ、ブランチ/マージを使用して共有リソースを取得および更新します
一見すると、共有フォルダーは有効な方法のように見えますが、私が一緒に仕事をしているクライアントは、Starteam でのそのアプローチで多くの問題を経験しており、TFS で再試行することに消極的です。私は現在、クライアントが Starteam から TFS に移行するのを支援している最中です。
各アプローチの長所と短所をリストしましたが、何かを見落としているかどうかはわかりません。
ワークスペース マッピング:
- セットアップと理解が簡単
- 複数の製品でライブラリの変更を簡単にテストできます
- ライブラリの最新の変更を簡単に取得し、ライブラリに変更を送信する
- 追跡可能性がない、または少なくとも追跡可能性が低い。たとえば、製品 A でライブラリの変更が導入された場合、製品 B でその変更を追跡する方法
- ライブラリの変更は、制御されていない方法で製品に影響を与える可能性があります
- ビルドが複雑になる
- 各ユーザーは自分のワークスペースを個別に設定する必要があります (ただし、TFS 2012 Power Tools にはワークスペース テンプレートがあります)。
フォルダ マッピング:
- 必要なものはすべて特定のブランチで構成されます
- 製品とブランチ間の分離
- ビルドが簡素化される
- 変更のより詳細な制御
- より多くのディスク容量が必要
- 分岐/マージおよび分岐の設定という形でより多くの管理が必要
特定の問題の 1 つは、複数の製品でライブラリの変更をテストする方法です。私が理解しているように、製品Aでのテストが必要であり、ライブラリへの逆統合と製品Bへの前方統合、その製品のテストなどを行います。
結論と最後の質問
クライアントは、Starteam でワークスペース マッピングに似たものを 10 年間使用して成功しており、TFS でもそのアプローチを引き続き使用する予定です。ただし、いくつかの製品に影響するライブラリの変更を追跡するという問題があります。
彼らは、フォルダーの共有が面倒で複雑になることを恐れています。
私の質問は、上記のリストで何かを見逃していませんか? 組織がワークスペース マッピングを使用してはならない理由、またはフォルダー共有を使用する必要がある理由は他にありますか?