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 software shop is such that we have 100+ projects in VSS ranging from small one-man-show projects to massive enterprise-wide applications.

We are trying to determine how to structure our projects in the transition and have, for the most part, decided on putting everything into one project site/system with each project having a subfolder off the root.

With this type of setup, we are concerned that we will lose a lot of the functionality that TFS provides (bug tracking, scrum burndowns, reporting, document storage etc.) because all the projects will be in the same portal/project space and it will be difficult to separate out individual project tickets/items.

Does anyone have experience with this? What was your solution? Did you stick with TFS?

Answer 1

I prefer not to have my IDE try to be smarter than I am. I prefer to keep the code writing, the defect tracking, the project management and the version control separate. Perhaps I am still leery from SSafe...

Try subversion. As for TFS it is really a tradeoff as to how you want to work.

Answer 2

Hello,

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.

HTH,

Colby Africa

Answer 3

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

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