Terje Sandstrom

------ Visual Studio ALM MVP ----- (also see new blog at http://hermit.no)

  Home  |   Contact  |   Syndication    |   Login
  64 Posts | 1 Stories | 116 Comments | 0 Trackbacks

News

Subscribe

Delicious Save this on Delicious Visual Studio Feeds

¨

Tag Cloud


Article Categories

Archives

Company stuff

Interesting bloggers

Interesting companies

Microsoft

Microsoft Norge

Microsoft Regional Directors

Microsoft Test

MSFT Blogs

MVP

NNUG

Other interesting stuff

TFS

Visual Studio

On codeplex the VSTS Rangers have published the Branching Guidance II (yes, a while ago, but still very true).  The basic idea there is the separation between 3 major branches,  the Main (or trunk), the Development and the Release branch.  One can elaborate on these and use multiple Development branches, and also a tree of release branches, but the basic principle can be summed up with these three.

image

 

Now, if we look at the different sets of build types we have, see http://geekswithblogs.net/terje/archive/2009/02/04/defining-the-build-set.aspx for details, and combine this information with the branching model above, we can see what types of builds should be set up for each branch.  I’ve used the terms None, Mandatory and Optional to indicate the relationships.

Builds \   Branches Development Main Release
Developer (CI build) Mandatory Mandatory Mandatory
QA build Mandatory Mandatory None/Optional
Deployment to Test Optional None Mandatory
Deployment to Production None None Mandatory

Some comments may be needed:

In any kind of branch, ALWAYS use a Check-in Build (for the Developer). It gives early warning if anything is going wrong.

Always use a QA Build (running daily/nightly at least) on your Development and Main branches, to ensure you have the right code quality, code coverage etc.  I say None/Optional on the Release branch, meaning if you do a lot of code changes there, it might be wise to run it also on the release branch, otherwise there should be no need.

Decide from where you want to release to your Test Systems.  You could choose any of the child branches, depending on how you want to ensure your quality.  If you’re making a large development effort, you need to go through a Quality Gate before you do a Reverse Integration back to main, then you should deploy to test from your Development branch. But you always need to test before release, so a deployment to Test should be done from the release branch.  A test on the development branch does only ensure the quality of the RI to main, you still need to do the Test on the release branch.

Deployment to production build should ONLY be done from the Release branch. Never ever from any of the other.

posted on Sunday, October 25, 2009 3:49 PM