Sep 27, 2010 at 8:38 PM
Edited Sep 27, 2010 at 8:48 PM
Let's separate the discussion into several key questions.
1. What is the best way for merging changes in a release branch (Service pack or Hot fix) into the Development branches?
The Rangers Branching Guidance recomnends normal merging processes for bringing such changes back to Main and then to the Development branches. In the Advanced plan, you would merge (RI) hot fixes into the Service Pack branch. Once there, they would be integrated
with other hot fixes and thoroughly tested before being shipped to customers. Then the Service Pack branch would be merged (RI) with the Main branch. Following the next good daily build of the Main branch it would be merged (FI) to each of the development
branches where it would indeed go through the rigor that Development or Feature branches go thorugh before they merge (RI) to Main. Bypassing this process by doing a baseless merge between a servicing branch (SP or Hotfix) and a Dev or Feature Team branch
is not recommended in the guidance.
2. Should there be an Integration layer between Main and the Dev (Feature) branches?
Adding an Integration layer between Main and the Dev (Feature Branches, may seem to provide some benefits. But in fact it comes with a cost. Each time you add a new *layer* to the branching structure, you double the merges required to move a change from
the Main branch to a Feature branch, or from a Feature Branch to the Main branch. At first it may seem that having this integration layer helps preserver the stability of the Main branch while Feature one is being *integrated* with Feature two or Feature three.
As you double the merges, you double the merge conflict resolution process which is where the real cost of branching is realized. For this reason we recommend, in the general case, not having an *Integration* layer.
Without the integration layer, where does the integration of Feature One with Feature Two happen? It should happen for the first time in one of these Feature branches. For example, when Feature One is ready to be released (and shared with other Feature teams),
it should be merged (RI) with Main. Main should be built on a daily basis. After every good build of Main you should merge (FI) Main with each of the Feature Team branches. Since this integration of Main and the Feature One branch has already happened and
has been tested in the Feature branch, the merge of the Feature Branch to Main should not significantly destabilize Main.
After the next good build of Main it will be merged (FI) to all of the Feature Teams (as mentioned earlier). When Main merges with Feature Team two, it will bring Feature one into the Feature 2 branch. This is where the integration of Feature one and Feature
two will happen. Only when this integration is tested and passes quality gates will the Feature two branch be merged with Main. At this time, Main will for the first time contain both Feature one and Feature two. Since the integration of Features one and two
have already been tested, the stability of Main should be at a high level.
The primary concern with this approach is slowing down the progress in a feature branch as it deals with the integration of another feature. Frankly this will be an issue whether you do the integration in a feature branch or in a separate integration layer.
Having automated Build Verification Tests (BVTs) will help improve the velocity of this integration, wherever it happens.
3. should there be an Integration layer between Main and the Release branches?
No. Integration is a development process. Once the code in Main has been thoroughly tested and determined to be ready to release, it should be branched to a Release branch. There is no benefit to having an integration layer at this point. In fact it will
simply slow down the process of moving code from Main to Release.. It is important to note that once you create a Release branch (or SP or Hotifx) you will not subsequently merge Main to any of these release branches. Doing so will probably pollute the Release
branch with untested code from Main that is being stablilized for a future release.
4. Should there be a common Integration Layer between Main and ALL of it's child branches?
This is the scenario in your diagram. The implications of this structure are scary (in my view, anyway). After you stabilize a new release (in Main) and are ready to release it to production, you have to merge Main with the Integration layer first, and then
merge (or preferably create) the release branches. But the Integration layer is likely to be less stable than Main. In fact it may be in the middle of integrating changes from D-F1 and D-F2. Putting a Development branch between Main and Release is sure to
cause stability and quality issues.
VS ALM Ranger
In the Rangers Branching Guidance, the r