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

Answer 2

I have two answers: what we do and what I suggest for you.

For us, we have a suite of web apps that all have MANY shared components. As such, although this is about 50 different assemblies (VS Projects) and 5-10 solutions (depending on how you look at it), there is very significant overlap across all of them which means we want to use TFS per-dev merging rather than branching and merging those overlapped resources. As such, we actually keep all of this in a single TFS Project. Here is how we have ours setup (names changed to make sense to you):

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

In our setup, we have a place for official company code. In addition, we have an area for people to go goof off without having fear of messing anything up yet while being able to take advantage of various TFS-related benefits.

However, in your scenario, if I'm reading between the lines correctly, I would suggest something different. My assumptions:

1. Each project, aside from having some common assemblies (I'm thinking logging, security, and other utility assemblies that are shared company-wide), are unrelated projects.
2. The shared/common assemblies are not regularly being changed so you can use DLL references rather than project references where you are always using the latest up-to-the-minute/day version of the code.
3. (TFS-based assumption as I'm still learning too) You can branch across Projects from the same Collection but you cannot branch across Collections.
4. Other than the above-mentioned shared assemblies, no other code is shared across teams.

So with these assumptions, I would go with something like this:

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

Doing it this way, you refer to the common assemblies via DLL references. You as the team or dev on a specific project get to decide when you begin to use a newer version of a common assembly. To do this, you simply get latest on that version's branch and then add a reference to it. If my assumption #3 is wrong, then hopefully you can do something better than that. Otherwise, each project has it's own space (that can contain more than just one VS Solution/Project which is a good idea) and your team has it's own collection to stay apart from the other teams.

Just my $0.02 worth...

Answer 3

We have taken a simple approach to third party components and created a separate project for them. Then when another project needs to reference the Assembly or DLL, we branch the folder the Assembly is in, into a "ThirdParty" folder in the target project.

This also gives us a mechanism for rolling out upgrades to Third party assemblies in a gradual way using a forward merge from the base folder.

Answer 4

Use Workspaces, they not only work across Team Collections but will work with most versioning techniques.