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

Reverse Integration for Bug Fixes

Aug 2, 2010 at 4:27 PM

Very basic question: If we make bug fixes in a Release branch and then move to Reverse Integrate these fixes into MAIN, it is quite possible that MAIN has 'moved on'. That is, the DEV branch may have introduced additional features by the time these fixes are ready.


Should we make the same fixes to DEV first (manually) and then push into MAIN? Or do we merge it directly with MAIN (hoping nothing breaks), push to DEV, recompile, push back to MAIN? Since MAIN has moved on, making these fixes directly to latest version of MAIN can have undesired consequences.


How is it usually done?

Aug 12, 2010 at 10:00 PM

This is an excellent question.

Generally once you release a new version (vCurrent) of a product (or solution), the Main branch is opened up for the next release (vNext). Most of the new development for vNext will be in a Dev branch (not the Main branch). For a period of time, the changes in Main are likely to be minor or primarily comprised of bug fixes or service pack releases that are merged (RI) from the release branches back to Main.  Changes in Main should be synced frequently (Merge, FI)  (daily builds, sync on good build) with the Dev branches. Since there are changes in Main and changes in Dev, there are likely to be merge conflicts that happen when you sync (merge FI) Main to Dev.

At some point, typically when the vNext Dev is ready for release (or testing) you would merge (RI) Dev to Main. At this point, there should not be significant merge conflicts. The frequent sync process we describe above should minimize the chances that there are significant changes in Main and significant changes in Dev that cause merge conflicts when merging Dev to Main (RI).

I hope this answers your question.


Bill Heys
VS ALM Ranger

Aug 13, 2010 at 2:48 AM
Edited Aug 13, 2010 at 2:48 AM


Interesting thoughts, thanks for sharing. 2 Questions:

1) I thought the release branches were always read-only because they were snapshots of what was released and is/was running on production servers(think Release Branch for Win95, Win98, Win2000, WinXP), why would I ever then RI from a release branch to Main? Shouldn't all production bug fixing happen on a Hot Fix branch then be RI into a Service Pack/Rollup branch and then RI to Main?

2) You mention sync/FI from a good build to Dev Branches. I've looked around and I haven't found any automated way to do this in either TFS 2008 or TFS 2010. I also don't see any scripts in the branching guidance that demonstrate how to do this, powershell, bat file, etc, I feel like I'm missing the implementation details to do this automatically. We still have trouble getting our senior developers to FI before they RI to main. Thoughts?

Aug 13, 2010 at 3:14 AM

In our branching guidance, we describe several branching patterns: basic, standard, advanced. Mostly these differ in terms of the complexity of your requirements on the release side. For example if you only need to support a current release, and you do not issue hot fixes or services packs, and you do not have a need to archive the released branch, you might consider the basic branch plan. However if you do require servicing (hot fixes and/or service packs) on the released code then consider the standard or advanced plan. In each these there is a servicing branch and perhaps a hot fix branch as weill as a release branch. In these last two patterns we would make the release branch (the lowest in the diagram) read-only to archive a snapshot of the code that is released. While archiving a snapshot is often a requirement and / or recommended, it is not alwyas needed. In the advanced branch plan there is both a service pack and hot fix branch. The concept here would be to create the SP, Hotfix and RElease branch all at the same time. Make the Release branch read-only. Make hot fixes in the hot fix branch (shipt them as patches). Roll up the hot fixes to a service pack (ship this as a patch) and roll this up to the Main branch. If you only have a basic plan, then all bug fixes to the released code would be made in the release branch and potentially rolled up to the Main branch. You have to pick the branch pattern (or a variation of the ones suggested) that best fits how you develop, release, and service your code.

I am  not suggesting an automatic merge from Main to Dev following a good daily build in Main. It should be part of a daily process, but not necessarily automated. Generally merging needs to be a manual process so that someone is available to resolve merge conflicts that cannot be automatically resolved by the tool.

If you are having trouble getting senior developers to follow best practices, if they won't FI from parent to child before they RI from child to parent (FI Main to Dev and then RI Dev to Main), they are reducing the stability of Main. My thoughts.. tell them they really aren't senior developers if this is their practice. (Just kidding.. but let me know how that works) :)

Bill Heys
VS ALM Ranger

Sep 22, 2010 at 7:15 PM


Thanks for your replies on this thread. A developer in my team sugested that FEATURE developers baseless-merge SP branch into DEV branch to ensure that those changes go thru the rigor that FEATURE branches go before they make it to MAIN. I of course dissagree as the advanced plan makes complete sense to me. However I proposed introducing an INTEGRATION branch in between MAIN and any child branch (all dev branches and SP->HF->RTM tree). Why would the advance branching strategy the rangers propose would leave SP work with a more relax situation that DEV? Dev I can force to have a MAIN build no older than n number of days, but with SP I cannot do that of course.





               / \       \

           /     \       \

         /           \       \

   D-F1     D-F2     SP






Am I missing some potential complexities by sugesting an INTEGRATION branch ?

If that is not necessary could you explain to me how I would reason the relaxed patch to MAIN that SP branch seem to have ?

Sep 27, 2010 at 9:38 PM
Edited Sep 27, 2010 at 9: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.

Bill Heys
VS ALM Ranger


In the Rangers Branching Guidance, the r