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

Branching Strategy - (dev, qa, uat, stage) to Branch Per Release

Jul 5, 2012 at 11:17 PM
Edited Jul 5, 2012 at 11:34 PM

I am new to TFS and I have stepped into the position. I walked into an existing TFS branch structure as follows:

DEV-> QA -> UAT -> STAGE

We have continuous builds with the help of CC.net for all branches.

Background:

From my understanding this branch structure was conceived to prevent the release engineer from having to rebranch each release branch per release and instead all branches are continuous. Stage serves as both the service branch and production branch in the traditional branch structure seen below. UAT is used for our user testing and QA is similar to the main branch in the traditional branch structure below.

I understand that the standard in the industry is the following to allow the use of multiple concurrent releases:

Dev <- Main -> Service Branch -> Release

But my question is if you utilize labels (in STAGE branch) with a continuous branch instead of branching per release does it save time from having to rebranch each release? I am finding that branching takes a fair amount of time to setup and reconfigure CC.net. Or maybe I am doing something the long/hard way, which I would appreciate some advice on how to make branching per release faster.

What are the flaws with this approach and do they outweigh the benefit of not having to rebranch each time?

Any advice is appreciated. But again I am new so if I am missing some underlying basics please inform me. Thank you for your help.

 

Jul 6, 2012 at 9:04 PM

Labels are generally frowned upon since what comprises a label can be changed and there is no history.  The benefit of having a release branch is it can be made read-only thus preserving the version of the release.  This is important for auditing, for example.  However, there is no right or wrong answer in how your branching should be setup.  You should have a service pack branch if production issues cannot wait until the next full release.  If this is never the case, then the service pack branch is not necessary.

Another approach is to branch off of Stage to a Service Pack branch and then do a release branch off of SP.  This way your integration builds will always point to a single Stage branch thus avoiding the configuration issues you are experiencing.  The result will look like the following:

DEV-> QA-> UAT-> STAGE-> SP-> Release

You would branch off of STAGE to new SP branches for each major release and maintain the single STAGE branch.  You could either deploy to production from STAGE or SP.  Release would be used for auditing only.

Jul 6, 2012 at 10:14 PM

Thank you for the response bminisi.

I'll try that out. =)

Jul 12, 2012 at 10:09 PM

My preference is to start with Main. Branch from Main to Dev to start on the next release. You can deploy (rather than branch) from Dev to QA. After QA signoff, merge (RI) Dev to Main for stabilization. Deploy (not branch) from Main to QA, UAT etc. Once stabilized in Main branch for Release (and optionally Servicing.

The branch structure for development: MAIN > DEV.

The branch structure for release: MAIN > SP (Optional) > RELEASE

Bill Heys, VS ALM Ranger

Jul 16, 2012 at 6:18 PM

Thanks Bill. This clarification helps. You guys are awesome!

Aug 23, 2012 at 12:19 AM
Edited Aug 23, 2012 at 12:20 AM

Actually I will move this to a new discussion.

We are a new Business Intelligence (BI) development team and whilst we are attempting to model a TFS branch plan that is easily manageable / automated I'm interested to hear how other in the Microsoft BI space are managing BI development through TFS.

Our IT team have a comprehensive TFS Workflow and Branch management scheme in place for their OLTP development, the BI side still requires TFS but not with the same complexity, after all BI has to be very nimble yet thoroughly tested etc.

Would love to hear thoughts on this.

Mar 7, 2013 at 2:24 PM
Hi Bill-

I do love the simplicity of the strategy but i have a couple of questions I'm hoping you can help me with.

After you deploy from DEV to QA or UAT, where do you start working on your next round of DEV changes? Because, what if there are necessary changes to the UAT code? Since there is no UAT branch, where would you do the changes so that they don't get jumbled with the next round of DEV? Same goes for changes to RELEASE for emergency bug fixes but I assume that in this case you manually write the changes into RELEASE and into DEV.

We have a single release web site for our customers. We do QA/UAT before releasing updates. We do separate DEV while code is in QA/UAT. My plan may involve a service branch but we may just do fixes in the RELEASE branch.

A little bit of guidance here would be a huge help and much appreciated.