How to Use Branching to Support a Release

- 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
  • Releases – Container for release branches
    • Release 1 – Release branch
      • Source

Keep the following recommendations in mind when working with Release branch:
  • When to branch – When you are ready to release, integrate everything into the Main branch and then create 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 – assign read/write permissions to all developers.
  • After release – Assign read/write permissions to developers working on hotfixes, read-only for everyone else.
  • Build frequency in branch – The builds are performed on-demand.
  • Testing focus in 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 Development or Main (integration) branches so that they 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 Development and Main (integration) branches.

Additional Resources

Last edited Jul 31, 2007 at 1:31 PM by prashantbansode, version 11

Comments

No comments yet.