私たちの小さな開発ショップは、プロジェクトをVSSからTFSに移行することを検討しており、TFSと他のプロジェクトを比較しています（まだトリガーを引いていません）。私たちのソフトウェアショップの性質は、VSSに100以上のプロジェクトがあり、小規模なワンマンショープロジェクトから大規模な企業全体のアプリケーションにまで及びます。
移行中のプロジェクトをどのように構成するかを決定しようとしています。ほとんどの場合、すべてを1つのプロジェクトサイト/システムに配置し、各プロジェクトのルートからサブフォルダーを削除することにしました。
このタイプのセットアップでは、すべてのプロジェクトが同じポータル/プロジェクトスペースにあり、TFSが提供する多くの機能（バグ追跡、スクラムバーンダウン、レポート、ドキュメントストレージなど）が失われることが懸念されます。個々のプロジェクトチケット/アイテムを分離することは困難になります。
誰かがこれを経験したことがありますか？あなたの解決策は何でしたか？TFSを使い続けましたか？
この質問に答えるには、TFS をどのように使用する予定であるか、製品に固有の制限があるのはどの機能かなど、いくつかの計画が必要です。私のアドバイスを次のように要約します。
プロセス テンプレートごとに [少なくとも] 1 つのチーム プロジェクトが必要です。つまり、2 つのチームが異なるプロセスを採用/カスタマイズする場合、それらを分離する必要があります。
条件 1 が満たされると、思ったほど多くの個別のチーム プロジェクトは必要なくなるでしょう。TFS の機能と設定の 90% は本質的に階層的であるため、各プロジェクトの必要に応じて範囲を広くまたは狭くすることができます。
詳細については、次を参照してください。
私が採用したアプローチは、アセンブリの論理グループごとにTFSプロジェクトを作成することでした。つまり、すべてのアプリケーションに共通のアセンブリを含むフレームワークプロジェクトがあり、見積もりシステム用に別のプロジェクトがあります。原価計算システムなど。ワークスペースのマッピングは少し「興味深い」ものになりますが、プロジェクトごとに、タイムスケールごとに異なる設計手法が可能になるため、1つのチームがスプリントの途中になる可能性があります（ほとんどのプロジェクトはチームシステムにスクラムを使用します）。別の時間が始まったばかりの時間...
TFS のすべての利点を得るには、個別のプロジェクトを使用するのが最善であることは事実ですが、これらの利点は、多くのプロジェクトの管理に関連する管理オーバーヘッドと比較検討する必要があります。数年前、私は Visual Source Safe を使用していました... Microsoft を辞めた後、Subversion に切り替えました。Microsoft に戻った後、私は TFS を使用していますが、これまでのところ非常に満足しています。
プロセス ガイダンス、レポート、統合されたバグ追跡、および緊密な IDE 統合は、私のニーズを完全に満たしています。さらに、TFS SDK では、いくつかの興味深い拡張シナリオが可能です。
私はいくつかの SCC プロバイダーを使用してきましたが、他のプロバイダーにはないすべての機能について TFS に落ち着きました。バグ相関、CI、および自動テストは、確かにメリットのリストのトップにありました。
複数のプロジェクトを使用するかどうかについては、プロジェクトが共通のコードを共有しているかどうかによって異なります。私たちはすべての「関連する」コード資産に TFS プロジェクトを使用する傾向があるため、同様のことを行い、多くのコードを共有するいくつかの異なるソリューションがある場合は、単一の TFS プロジェクトを使用します。共通点がなければ、別々のプロジェクトになります。
この記事が古くなっていることは承知していますが、TFS 2010 では、チーム プロジェクト コレクションという素晴らしい機能がサポートされるようになりました。これは、プロジェクトに基づく別のレベルの間接化またはグループ化です。
これにより、名前空間を詰まらせることなくチーム プロジェクトを簡単に作成できるようになり、より良い組織化が促進されます!
コレクションについて詳しく説明している素晴らしいリンク
http://blogs.msdn.com/b/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx
私はSharePointユーザーではありませんが、Sharepointコレクションと非常によく似た概念を聞いています:)
これが 2008 年に修正されたかどうかはわかりませんが、2005 年にルート プロジェクトのサブフォルダーであるプロジェクトをビルドすると、MSBuild はルート プロジェクトのソース ツリー全体 (サブフォルダーの一部ではないファイルも含む) をプルします。
管理しているソースの量によっては、ビルド時間が大幅に増加する可能性があります。