Project structure in TFS 2010

Question

We have just gotten TFS 2010 up and running. We will be migrating our source into TFS but I have a question on how to organize the code.

TFS 2010 has a new concept of project collections so I have decided that different groups within our organization will get their own group. My team develops many different web applications and we have several shared components. We also use a few third party components (such as telerik).

Clearly each web application is it's own project but where do I put the shared components? Should each component be in it's own project with separate builds and work items?

Is there a best practice or recommended way to do this specific to TFS 2010?

Answer 1

The best practice for this is to have everything that you need to build a solution under your Main/Trunk folder. We use the following format:

 "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)

This keeps all of your branches at the same level so you do not have any doubt as to which is a branch and which is a folder.

That's your Team Project structure, but what about the actual folder structure under each of the branches:

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)

The idea is that it is the team's choice whether to use a new version of an external product or reference library. Just because one team can upgrade to a new version of NUnit does not mean that another team chooses not to as it is weeks of work.

By all means have a central "Tools" project that you always update with the latest and your team pulls from there, but do not have external dependencies. It makes it a nightmare to do automated builds and makes your developers upgrade even if it is not a good time. On top of that make sure you treat any external dependency as a Tool even if it is from another internal team.

References: TFS Deployer