Question: How should I manage my team projects?

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

Answer

Team projects are intended to represent the largest unit of work possible in your organization. Most often this will be a product under development.

Consider one of the following strategies for managing team projects:
  • Create one project per application.
  • Create one project per release.

Create one project per application

If you want to carry forward not only source code but also work items and other TFS assets between releases, consider using one project per application. When you use a single project for multiple versions of the application, all of the TFS assets are carried forward automatically for you 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.

The following are reasons not to use one project per application:
  • Releases in parallel are forced to share work item schemas, 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 eliminate this baggage is to create a new team project and then branch code you want to carry forward into that project.

Create one project per release

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.

The following are reasons not to use one project per release:
  • While 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’ll need to write your own utility.
  • If you have hundreds of applications and releases, each in its own project, you’ll hit Team Foundation Server performance and scale limits.

Keep the following considerations in mind when choosing your strategy:
  • Choose a structure that will suit your purposes in the long term, because restructuring existing team projects is difficult.
  • Source can be easily shared among team projects as follows:
    • 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 Development (MSF Agile) process template, or 250 projects using the MSF for CMMI® (MSF CMMI) process template. If you create your own process or customize an existing template, keep in mind that work item schemas have the largest impact on server scalability. A complex schema will result in a server capable of supporting fewer projects.

Additional Resources


Last edited Jul 19, 2007 at 12:02 AM by jtaylorsi, version 5

Comments

No comments yet.