An important factor in using TS effectively is having the right Team Project design and having a solid plan for Configuration Management.

It is important to understand major issues related to projects and TS features because a bad design can cripple your development process, and you might have to start over.

A good starting point is to know the scope of a Team Project and what it contains, and to understand how branching and merging works with this. There are many good articles with related information but I have not come across any advice on a solution.

So, I’ll try to explain what I designed and why and leave you to read about Team Projects and merging/branching.

As you may know, a Team Project is a container for items like source control, work-items, documents, etc. What these items could be is configurable at a higher level with Templates (there are 2 provided out of the box). Project reports, documents, etc. are available at a Team Project level. Most dev teams work on a number of products which are maintained over time and enhanced over release cycles, mostly with parallel development. Instinctively, one would think of having 1 Team Project per Product and also maybe 1 Team Project per release in order to manage a release tightly and eventually do some merging across releases, etc.

Unfortunately, there are limitations of not being able to move artifacts like Work Items, etc. across Team Projects and one has to consider the implications of those before running off and happily creating Team Projects. It is likely that different products share features or a part of the code-base and bug-fixes or enhancements need to be propogated across projects. In most realistic situations, a bug (read Work Item) slated for 1 release may get pushed to another. Given the limitations and requirements, the conclusion is to have 1 Team project for the entire Product line, assuming these Products are similar and share features and the code-base.

The downside of this is that the Team Project is one mother-lode and granularity is lost at a product or release level. I hope the limitations are addressed in future TS versions, but till then one might have to customize Reports and other things to get information at a Product/Release level. If you have other ideas or workarounds, please post them.

Given the assumption of using 1 Team Project, I will talk about Configuration Management (branching/merging, building, etc.) later…