This project is read-only.

Question: How do I use branching to release my application?

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


Use a Release branch when you are ready to stabilize your build prior to release.

The following is an example of what your branch structure might look like after you have created a Release branch:
  • Main – Integration branch
    • Source
    • Other asset folders
  • Release 1 – Release branch
    • Source

Keep the following recommendations in mind when working with a Release branch:
  • When to branch: When you are ready to release, integrate everything into the Main branch and then create a Release branch that can be used to stabilize the application prior to release.
  • When not to branch: If you are using one TFS project per release, you can use the new project to continue development instead of a branch in the current project.
  • Permissions on branch:
  • Prior to release – Read/write for all developers.
  • After release – Read/write for developers working on hotfixes, read-only for everyone else.
  • Build frequency on branch: On-demand builds.
  • Testing focus on branch: Sign off on release.

You should use the Release branch for the targeted fixes and changes necessary in order to stabilize a build prior to release. Development of the next version of your application can occur in parallel in your main Development or Integration branch so that the new version can get the benefit of the stabilization changes you made prior to release. After a final release build has been created, you can merge the changes from the Release branch back into your main Development and Integration branches.

Additional Resources

For additional descriptions of how to branch and merge in Visual Studio 2005, see “Branching and Merging Team Foundation Source Control” at

Last edited Jul 18, 2007 at 11:08 PM by jtaylorsi, version 6


No comments yet.