Team Development with Visual Studio Team Foundation Server

Create One Team Project per Application if You Want to Migrate Work
Items and Other Assets Between Application Versions
If you want to carry forward not only source code but also work items and other TFS
assets between releases, consider using one team project per application. When you use a
single team project for multiple versions of the application, all of the TFS assets are
carried forward automatically for the next release. When you are ready to release a new
version of your application, you can create a branch within the project to represent the
release and isolate that code.
Keep the following key points in mind when using one project per application:
• Parallel releases are forced to share work items schema, check in policies, and
process guidance.
• Reporting is more difficult; because reports default to the entire project, you must add
filtering by release.
• If you have hundreds of applications, each in its own project, you will run up against
TFS performance and scale limits.
• You will accumulate ‘baggage’ over multiple releases. The easiest way to address this
issue is to create a new project and branch the code you want to carry forward into
that project.
Additional Resources
• For more information about using team projects, see “When to use Team Projects” at
http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx
Create One Team Project per Version if You Want to Start with New Work
Items and Other Assets with Each Application Version
If you want each release to start fresh without carrying forward work items and other TFS
assets, consider using one project per release. When you use a new project for each
release, you can modify work item schema, workflow, check-in policies, and other assets
without impacting the old release. This can be especially useful if the old release will be
maintained by a separate team such as a sustained engineering team who may have a
different process and workflow than your main development team.
Keep the following key points in mind when using one project per release:
• Although it is very easy to move the source code from one project to another, it is
difficult to move work items and other TFS assets from one project to another.
Because work items can only be copied one at a time to another project, if you want
to copy sets of work items, you will need to write your own utility.
• If you have hundreds of applications and releases, each in its own project, you will
run up against TFS performance and scale limits.
• Choose a structure you can live with in the long term because restructuring existing
team projects is difficult.
• Source can be easily shared among team projects as follows:
o Branch source from one project to another.
o Map source from another project into your workspace.