This project has moved and is read-only. For the latest updates, please go here.

Do we really need service branch?

Nov 9, 2011 at 1:59 AM

Hi all,

We have a single client with only a single release in production at a given time.  We are using the standard branch plan with service branches and read only release branches created when we deploy a release to production.

My question: given that we only have a single release in production at a given time is there any need to have both a service and release branch?  Can we just apply our fixes to the release branch and build/deploy from it?






Nov 9, 2011 at 2:07 AM

When do you need both a service AND a release branch? When you need both a read-only copy of the code you released (for auditing or legal purposes, for example) and when you need to do post-release servicing (such as hot fixes and / or service packs). If you do not need a read-only archive copy of your major release, then you might consider combining the service and release branch into one. On the other hand why not have both. The overhead is minimal. I did a blog on this a few months ago. How frequently do you issue a new release?


Bill Heys
VS ALM Ranger


Nov 9, 2011 at 2:20 AM

Bill, thanks for the quick reply - very much appreciated.

We do a release to production about one every two months. On average we probably do one or two hotfixes to a release.  We do not have a legal requirement, although it would be nice for auditing purposes.  Can you point me to your blog?

On a related note - in the standard branch setup, once a release branch is created and made read only its it ever updated with any hotfixes from the service branch, or is the release branch a true point in time copy of that production release?






Nov 9, 2011 at 2:25 AM

My blog on this:

When you make a release branch read-only, the intent is that it NEVER gets updated. Making it read-only is the most reliable way of preserving a branch at a point in time. Labels in TFS are NOT immutable. You can change the contents of a label at some point in the future.