This project has moved and is read-only. For the latest updates, please go here.

Beginner issue: Structuring TFS the right way

May 12, 2011 at 2:44 PM

I'm taking over TFS for a company I just hired on at.  I've worked with TFS but never setup projects.  I want to restructure TFS here, get it started "the right way".


As I understand it we should have a Team Project for items that the business would consider a product, this lets us encapsulate releases better. (correct?)

What I mean is we have a number of projects/solutions :

"Core code" shared between multiple projects

A RIA style web site, that "hosts" other applications

The individual applications "hosted" in the RIA web site

Other projects not related to the website or apps that use some of the core code. (~10+ right now)

Should I have 3+ team projects?  I have seen some say that it is better/easier to use fewer team projects.


The situation I want to avoid is this:

If we have one project for Core/WebSite/WebApplications then any time I need to release an update to a web app or the hosting site, I have to have a release branch that contains everything else (core/website/ all webapps).


Really looking for some help here since it is so difficult to restructure things later.

May 12, 2011 at 8:11 PM
Edited May 12, 2011 at 8:17 PM

You've probably got many questions folded into "structuring TFS the right way". The first topic is "TFS Team Project(s)" so I'll start there.

Consider putting all projects into a single "TFS Team Project" unless you have a reason for using separate TFS Team Projects (need different TFS Work Item Templates (custom/different work item workflow processes), fundamental difference in release cadence, etc). It's a common misconception that you have to have a separate TFS Team Project for each product or even each set of branches.

I recommend reading the following articles:

  • "When should I use Areas in TFS instead of Team Projects in Team Foundation Server 2010" by Martin Hinshelwood 3/9/2010 (updated 4/13/2010)
    • Great list of pros and 5 cons to consider plus screenshot walkthrough creating structure for several projects in a consolidated TFS Team Project.
  • Project of Projects with team Foundation Server 2010 by Martin Hinshelwood 1/4/2011
    • I'm a sucker for descriptions with inline annotated screenshots and this particular blog has screenshots in spades.
    • Source code folders, Iteration Paths, Area Paths,
  • Build Folders by Brian Harry 4/1/2011
    • Use a Build Definition naming convention even if you don't use the plug-in discussed. If you consolidate projects in a single TFS Team Project then naming convention is even more important!

You can also build and branch between team projects if you need so creating (or migrating to) a consolidated TFS Team Project is not a requirement. I've found this a bit conceptually challenging... especially when I start thinking about archiving Team Projects.

These should give you a great start.

Enjoy! -Zephan



May 13, 2011 at 10:10 PM

I don't necessarily agree (nor do I necessarily agree with Martin and the other referenced sources) with respect to the basic approach for organizing Team Projects.

The VS ALM Ranger team recently published an MSDN article on Team Project Collections and Team Projects ( In this article, we tried to describe various considerations for deciding when (or wnen not) to combine Visual Studio Projects / Solutions into a single Team Project vs organizing them into separate Team Projects. As Zephan indicated ealier, each Team Project has its own Process Template. So if you had two project teams, and one wanted to use the MSF for Agile Development v5.0 process template while the second team wanted to use the MSF for CMMI Process Improvement v5.0 process template, then they would each have to be working in their own Team Project.

Likewise, if you wanted a different security model (where the tech lead of one team with branching permissions in his / her own team project, should not be permitted to branch the code for the second team project, or where developers on one team are only able to check code into branches in their own team project and not into branches in the second team's team project) - then isolating these two teams into separate team projects might be the answer.

I generally prefer to think of Project Intitiatives (a project with a set of requirements, a plan, a team, a set of milestones, a release schedule, etc that is different from another project iniative in my organization).  I like to organize my Project Initiative into its own Team Project. This offers the advantage that the project team has control over choice of process template, process template customization, work item / work flow customization, report and query customization - and does not need to reach consensus with other proejct teams on these decisions).

Within the Team Project, I tend to like having a single branching strategy for the project initiative that takes into account how the team develops software (waterfall, iterative, agile, Scrum,etc). As well the branching strategy should take into account how the team releases and supports software (do they release once every two years, do require sustained engineering - hot fixes and service packs for one or more production releases, do they have four-week sprints, do they have iterative releases. How many parallel releases do they support. How many service packs per release, etc). When it comes to archiving a the code for a Project Initiative - it is easier to achieve when that Project Initiative has its own Team Project. It is very hard to archive *part* of a Team Project.

I generally perfer to use the Areas feature of a Team Project for categorizing or organzing the code within my solution - rather than using it to organize multiple teams and solutions which could be in separate Team Projects but we decided to colocate them within the same Team Project. So although you CAN have multiple Teams working within the same Team Project, and you can use Areas to organize them, I generally don't like this approach. When I want to isolate two teams I like to use Team Projects as my isolation mechanism.

Having said that, if you like the concept of project of projects and the ease of reporting that you can achieve when everything is contained in one Team Project, by all means follow the suggestions in Martin's two blogs.

It is possible to query and report across Team Projects. It is also possible to branch across Team Projects (for example having shared code in one Team Project and then sharing that code to multiple other Team Projects - leverages the ability to branch across Team Project boundaries.

From the opposing view point :-)

Bill Heys
VS ALM Ranger