This project has moved. For the latest updates, please go here.

Single or multiple release branches using basic plan

Jul 11, 2012 at 9:11 AM

We have a development team who mainly produce internal systems and so really only have to support a single release at any one time. 

We are following the basic branching plan in the VS2010 branching guide and this states:

Additional releases are supported by creating additional release branches for each product release.  Each release branch is a child of MAIN and a peer to each other (e.g. release2.0 branch is peer to release3.0 and both are children of MAIN)

The quick start guide seems to suggest having a single release branch and labelling it each time you do a new release (the example in section Release 1.1 to Production is to merge main to release and 'Finally label the "Release" branch as "Release 1.1" and complete the new release process (Go Live)'.

My interpretation of this is that having one release branch and labeling this is acceptable, and if the need arises you can add additional release branches? Firstly is this assumption correct and secondarily what circumstances generally necessitate this?   

 Many thanks. 

Jul 11, 2012 at 12:36 PM

The simple labeling approach can certainly work in some cases. Yours may be one of those. But it is very simple. There are some pitfalls to assess. Here are two.

First, if you read some of the other posts, you will see people caution you that labeling is not good if you need an authoritative snapshot since labels can be modified. If that concerns you, consider their advice.

Second, one thing to watch with this simplified model is where you deploy your release from. Up until the time the new release is in production, you will want to reserve the right to make changes to the previous release because it is live. What you would NOT want to do is merge from dev to main, then to the release branch, then undertake a multi-week testing protocol with the new release in your release branch and no way to do hotfixes on the old release.  That would be the wrong way to use the model. Instead, you would want to stabilize the new product and get it acceptance-tested and deployed from another branch (like Main). Then you could promote it (merge it) to the release branch at the time it is deployed.

These two nuisances are just some of the reasons why some of us just make a separate release branch for each release. It's clean, it's simple, and it avoids lots of problems. The only reason I can imagine for NOT having separate branches would be if your source code is HUGE and you cannot afford the storage space of multiple releases, and you have lots of releases.

But you certainly can use a shared release branch if you are aware of its limitations and they do not apply.

 

 

Developer
Jul 12, 2012 at 11:19 PM

With respect to Labeling vs Branches for release, I agree with David. Label contents can be changed and are not auditable. I had hoped to correct the scenario in the Branching Guidance (2010) so it no longer recommended labeling. 

With respect to space issues, TFS does not generally make full copies of files when branching. See my blog: http://blogs.msdn.com/b/billheys/archive/2011/05/05/how-tfs-stores-files-and-calculated-deltas-on-versioned-files.aspx

Bill Heys, VS ALM Ranger

Jul 13, 2012 at 10:06 PM

Thank you for the feedback, I think the points about auditability and the release deployment are excellent ones. I shall revert to the multiple release branches. 

When several releases have taken place I was thinking I would need to delete the older release branches as they are no longer required and could cause confusion, is there any reason not to do this? Would I be better just locking them or using some other functionality? 

Developer
Jul 14, 2012 at 12:20 AM

I would keep, at a minimum, the release branch(es) for each release version you need to suppport (in production). And I would keep them for as long as you need to service these releases (service packs, and  /or hot fixes (bug fixes)). You should also understand the audit requirements for preserving released code (for example some organizations have a seven-year audit requirement), Having said this, if you have have reliable backup and recovery procedures, AND you are able to restore a prior version (and maybe upgrade to your current TFS environment) these "release branches" may not all NEED to be in the active TFS database.

Consider a product you released three years ago but still needs to be supported for current customers, do you have everything you need checked into TFS - including third party or common code/DLLs, .NET Framework DLLs, etc? Can you recreate the developent environment from 3 or 5 years ago? If not you should have a well thought-out plan in place.

Bill Heys