This project is read-only.

Create One Team Project per Version if You Want to Start Fresh With Each Application Version

- J.D. Meier, Jason Taylor, Alex Mackman, Prashant Bansode

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 schemas, 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.

When using one project per release, keep the following in mind:
  • 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. 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:
    • Branch source from one project to another.
    • Map source from another project into your workspace.
  • Team Foundation Server can scale to ~500 projects by using the Microsoft Solution Framework (MSF) for Agile Software Development (MSF Agile) process template or to 250 projects by using the MSF CMMI process template. If you create your own process, or customize an existing process, keep in mind that the work item schema has the greatest impact on server scalability. A complex schema will result in a server capable of supporting fewer projects.

Additional Resources

Last edited Jul 26, 2007 at 11:35 AM by prashantbansode, version 3


No comments yet.