TFS Structure - Multiple Projects or Single Project?

Question

Our small development shop is looking to migrate our projects from VSS to TFS, and we\'re evaluating TFS vs. others (haven\'t pulled the trigger quite yet). The nature of our s

Answer 1

The answer to this question requires some planning on your part: how you intend to use TFS, and which of those capabilities has inherent limitations in the product. I would summarize my advice as:

1. You will need [at least] 1 team project per process template. That is, if two teams want to adopt / customize different processes, they will need to be separated.

2. Once condition #1 is satisfied, you probably don't need as many separate Team Projects as you think. 90% of TFS features & settings are hierarchical in nature, allowing you to scope them as broadly or narrowly as each of your projects requires.

For complete details, see:

• http://www.codeplex.com/BranchingGuidance/Wiki/View.aspx?title=Guidance%20for%20Structuring%20Team%20Projects
• http://blogs.msdn.com/richardb/archive/2007/05/01/tfs-team-project-whitepaper.aspx
• http://msdn2.microsoft.com/en-us/library/aa974183(vs.80).aspx

Answer 2

I've used several SCC providers and we've settled on TFS for all of the features it has that others don't. Bug correlation, CI and automated testing certainly topped the list of benefits.

As for whether you use multiple project or not, I'd say it depends on if the projects share any common code. We tend to use a TFS project for all "related" code assets, so if we have several different solutions that do similar things and share a lot of code, we use a single TFS project. If they have nothing in common, then they become separate projects.

Answer 3

I realize this article is old, but TFS 2010 now supports a wonderful feature call Team Project Collections which is simply another level of indirection or grouping on top of Projects.

This makes it much easier to create Team Projects without clogging up your namespace and encourages better organization!

Great Link talking more about Collections

http://blogs.msdn.com/b/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx

I a not a sharepoint user but I hear its very similar concept to Sharepoint collections :)

Answer 4

I am not sure if this was fixed in 2008 but in 2005 when you built a project that was a subfolder of a root project, MSBuild will pull the entire source tree of the root project - even files that are not part of your subfolder.

Depending on how much source you are managing this can greatly increase your build times.

Answer 5

The approach I've taken was to have a TFS project for each logical grouping of assemblies -- So we've a framework project that contains assemblies common to all our applicaitons, we then have a separate project for our quotations system, another for the costing system and so forth. Whilst the workspace mappings get a bit "interesting", it does allow different design methodologies for different projects, and at different timescales -- so one team might be half way through a sprint (Most projects use Scrum for Team System), at the same time as another is just starting...

Answer 6

It is true that to garner all of the benefits of TFS, it is best to use separate projects, but those benefits should be weighed against the administrative overhead associated with managing many projects. Years ago, I used Visual Source Safe...After I left Microsoft, I switched to Subversion. After returning to Microsoft, I am using TFS and so far I am very happy with it.

The process guidance, the reports, the integrated bugtracking, and the tight IDE integration serve my needs perfectly. Plus, the TFS SDK allows for some interesting extensibiilty scenarios.