TFS Team Project whitepaper

  • Article

As promised, we finally have some guidance around structuring team projects.  What can you do within a team project?  What can you migrate between projects?  Which settings are global, which are scoped only to Team Projects, and which can be broken into their own hierarchies?  Doug Neumann reveals all.  Here's an overview of what he covers:

What is a Team Project?

Strategies for Employing Team Projects

    • Strategy 1: Team Project Per Application
    • Strategy 2: Team Project Per Release
    • Strategy 3: Team Project Per Team

Providing Substructure Within a Team Project

Other Common Questions

What limits are there within a single team project, anyway?  My answer has long been: almost none.  Don't skim the big chart under "providing substructure" -- those are all important features we use extensively.  After all, the entire Developer Division (Visual Studio, Team System, TFS, Silverlight...) works in one team project.  I usually don't recommend creating a new TP unless there's a specific feature you can't get any other way.

Another rule of thumb I've used when answering customer questions is to have a one-to-one mapping between TPs and process templates.  To me a TP represents not just a "collection of artifacts" but a physical instantiation of your abstract development process/workflow.  Currently, if you create a new process template, you have no choice: TFS won't let you update an existing TP, apart from minor changes (e.g. uploading new work item types).  More conceptually, if you're feeling like your process needs to change, it's a sign you may need to create a new TP in the future. 

Perhaps more controversially, I think the relationship works in the other direction: you usually don't need more than one TP per process template.  If several teams are planning to adopt the same process, they can probably share the same TP.  Similarly, if you're happy with a process currently in place and don't plan to change it, you probably don't need to create another TP just because you hit a certain release milestone or finished servicing a certain customer.  Again, use the extensive charts in the article as a checklist to make sure your team project can really handle this -- my guess is you'll be pleasantly surprised.

Note: all recommendations above are my own, not those of Doug, the TFS team, or Microsoft