TFS2010が稼働し始めました。ソースをTFSに移行しますが、コードを整理する方法について質問があります。
TFS 2010にはプロジェクトコレクションの新しい概念があるため、組織内のさまざまなグループが独自のグループを取得することにしました。私のチームは多くの異なるWebアプリケーションを開発しており、いくつかの共有コンポーネントがあります。また、いくつかのサードパーティコンポーネント（telerikなど）も使用しています。
明らかに、各Webアプリケーションは独自のプロジェクトですが、共有コンポーネントはどこに配置すればよいですか？各コンポーネントは、個別のビルドと作業項目を持つ独自のプロジェクトに含める必要がありますか？
TFS 2010に固有のこれを行うためのベストプラクティスまたは推奨される方法はありますか？
このためのベストプラクティスは、メイン/トランクフォルダーの下にソリューションを構築するために必要なすべてのものを用意することです。次の形式を使用します。
"Project 1"
"DEV" (Folder)
"Feature 1" (Branch)
"Main" (Root branch)
"Release" (Folder)
"Release 1" (Branch)
"RTM" (Folder)
"Release 1.0" (Branch)
"Release 1.1" (Branch)
これにより、すべてのブランチが同じレベルに保たれるため、どちらがブランチで、どちらがフォルダーであるかを疑うことはありません。
これがチームプロジェクトの構造ですが、各ブランチの下の実際のフォルダー構造についてはどうでしょうか。
Main (Root branch)
"Builds" (Folder that contains all of the MSBuild and Workflows for building)
"Documents" (Folder that contains version specific documents)
"Deployment" (Folder that contains config required for deployment | We use TFS Deployer from Codeplex)
"Setup" (Folder contains all of the setup resources)
"[Company].[Namespace].*" (Folders that contains a project)
"Tools" ( Folder for all your nuts and bolts)
"Toolname" (Folder for a specific tool or reference library)
アイデアは、外部製品の新しいバージョンを使用するか、参照ライブラリを使用するかはチームの選択であるということです。あるチームが新しいバージョンのNUnitにアップグレードできるからといって、別のチームが数週間の作業であるため、アップグレードしないことを選択したわけではありません。
必ず、常に最新の状態で更新し、チームがそこからプルする中央の「ツール」プロジェクトを用意してください。ただし、外部の依存関係はありません。自動ビルドを行うのは悪夢であり、良い時期ではない場合でも開発者をアップグレードさせます。その上、別の内部チームからのものであっても、外部の依存関係をツールとして扱うようにしてください。
参照： TFS Deployer
私には2つの答えがあります：私たちがしていることと私があなたに提案することです。
私たちには、すべてが多くの共有コンポーネントを持つ一連のWebアプリがあります。そのため、これは約50の異なるアセンブリ（VSプロジェクト）と5〜10のソリューション（見方によって異なります）ですが、それらすべてに非常に大きな重複があります。つまり、開発ごとのTFSマージを使用する必要があります。それらの重複したリソースを分岐してマージするよりも。そのため、実際にはこれらすべてを1つのTFSプロジェクトに保持しています。これが私たちのセットアップ方法です（あなたにとって意味のある名前に変更されました）：
"Official Projects" (Collection)
"Production Applications" (Project)
"Technology Proof of Concepts" (Project)
"Reference Projects" (Project) - this is a simple solution/projects using our architecture to make our architecture easier to understand as people join our team. Other reference apps will go here in the future.
"TFS Configuration" (Project)
"Playground" (Collection)
"John Doe" (Project)
"Jane Doe" (Project)
"Security Team" (Project)
"Production Test" (Project)
私たちのセットアップでは、公式の会社コードの場所があります。さらに、TFSに関連するさまざまなメリットを活用しながら、何も台無しにすることを恐れずに、人々が失敗する領域があります。
ただし、あなたのシナリオでは、行間を正しく読んでいる場合は、別のことを提案します。私の仮定：
したがって、これらの仮定では、次のようなものを使用します。
"Common Resources" (Collection)
"Source" (Project) - everything goes here such as logging assemblies, security assemblies, etc.
"Version 1" (Project) - Branch as you "rev" your common assemblies so people have access to older versions.
"Version 2" (Project)
"Version 3" (Project"
etc.
"Team 1" (Collection)
"Project 1"
"Project 2"
"Project 3"
"Project 4"
"Project 5"
"Team 2" (Collection)
"Project 1"
"Project 2"
"Project 3"
"Team 3" (Collection)
"Project 1"
"Project 2"
etc.
このようにすると、DLL参照を介して共通のアセンブリを参照します。特定のプロジェクトのチームまたは開発者は、新しいバージョンの共通アセンブリの使用をいつ開始するかを決定できます。これを行うには、そのバージョンのブランチの最新情報を入手して、そのバージョンへの参照を追加するだけです。私の仮定＃3が間違っている場合は、うまくいけば、それよりも優れたことができます。それ以外の場合、各プロジェクトには独自のスペースがあり（VSソリューション/プロジェクトを複数含めることができます。これは良い考えです）、チームには他のチームから離れた独自のコレクションがあります。
ちょうど私の0.02ドルの価値...
サードパーティのコンポーネントに簡単なアプローチを取り、それらのために別のプロジェクトを作成しました。次に、別のプロジェクトがアセンブリまたはDLLを参照する必要がある場合、アセンブリが含まれるフォルダーをターゲットプロジェクトの「ThirdParty」フォルダーに分岐します。
これにより、ベースフォルダーからのフォワードマージを使用して、サードパーティアセンブリへのアップグレードを段階的に展開するためのメカニズムも提供されます。
ワークスペースを使用すると、チームコレクション全体で機能するだけでなく、ほとんどのバージョン管理手法で機能します。