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

What do you build your test release from?

Apr 29, 2010 at 4:58 PM

I have been working recently to understand the recommended strategies for branching within TFS for a project that we have in our company that is growing in complexity. I have been trying to understand the point at which you generally send your completed work package off to the test team for the "Feature Crew" model.

As far as I understand it, if you have a structure such as the following:



And you create a branch such as:


When my team working on the dev branch above finish developing the required features and believe they all work together, what do we build off to produce a 'Test Build'? The options are Scenario1: to build off the branch to get a set of binaries. Alternativly, Scenario2: the 'MyFeatureBranch1' could be merged back with MAIN and then the Test build created from that.

Quite a lot of the time the TFS guides seem to suggest Secnario 2 is the preffered option but this contidicts the advice in the "Team Foundation Server Branching Guidance" (VS 2005) docuement (p22, bullet point that starts "Keeping the MAIN branch customer ready...") as it is unlikely that the feature set has been properly stabalised prior to testing. It does carry the advantage that changes are propegated to the feature teams quickly as they are regualry forward integrating from MAIN.
Also, in Scenario 2, given that no code changes can be applied directly to MAIN, where would bug fixes to the feature set actually be done? Would you create a Release branch and then fix them there?

Secnario 1 seems the safest bet, but is not generally favoured by the guides. The updates to MAIN will be a lot slower here as it has to complete the test cycle. However, MAIN will always be very close to "Customer ready". The only option in Scenario 1 is to apply bug fixes found in test to the Dev branch and then merge ith MAIN when stable.

Any Ideas?



Apr 29, 2010 at 5:39 PM


I recommend a combination of Scenario 1 and Scenario 2. Before you merge changes from MyFeatureBranch1 (RI) back into Main, you want to make sure that the code in MyFeatureBranch1 passes necessary quality gates. One way to do this is to deploy the code from MyFeatureBranch1 to a test team (QA). Once QA asserts that the code in MyFeatureBranch1 is *ready to share* or *ready to release*, you would merge it (RI) back to Main. At this point, you could continue building and testing Main by deploying it to QA for further stabilization tests.

Bugs found should generally be fixed in the branch where they are found. If you find bugs in Main during stabilization, you must decide whether to fix directly in Main or to fix in the development branch and merge back to Main.

Following the process described above should meet the goal you quote "Keeping the Main branch customer ready". As far as I am aware, all of our guidance tries to stress the point that the Main branch should be kept as stable as possible.

I would not suggest creating a release branch until you are ready to release the code. Therefore, pre-release bugs are fixed in Main or Development. Post-release bugs are fixed in a Release branch. This would hold true for both Scenario 1 and Scenario 2 above.


Bill Heys
VS ALM Ranger