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.