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

How to insert integration branch?

Mar 7, 2014 at 7:33 PM
Edited Mar 7, 2014 at 8:07 PM
Hi there
In my team, we currently have a Main branch parent of 3 development branches (let's call them A, B, C), so here's the situation:

Main -> Dev A
Main -> Dev B
Main -> Dev C

As we like to keep our Main branch clean and always ready for the next release, we don't like the idea of merging directly to Main as we often have to do some more integration before the changes fully work. We would like to use the integration branch plan/pattern so that our situation would become:

Main -> Integ -> Dev A
Main -> Integ -> Dev B
Main -> Integ -> Dev C

This way, integration changes would happen in the integration branch and be able to be FI to the children dev branches, as well as RI into Main when fully integrated. And Main would always be ready for release.

Take note... We have ongoing changes happening in our 3 development branches, and they will not be part of the same release.

How exactly do I insert the Integration branch? I know about re-parenting and baseless merges, but I'm not sure in which order and from which to which I should be doing things, without risking losing changes or integrating too much of them in the wrong branches.

Thanks for your help!
Mar 8, 2014 at 6:24 AM
Edited Mar 8, 2014 at 6:57 AM

We follow a little deviated process from the Guide and I thought to share the same with you. We use the MAIN branch for QA/Test and the Integration branch for Developer testing (Developer Inegration Testing actually). That gives us required isolation between deliveries to Test team and Developer Integration testing. It frees the Integration test branch when QA/Test team are testing on a particular branch. Had we used the Integration branch for QA/Test team testing, then the branch would be 'in use' as they might need to perform GETs several times and the codebase should not be changed during that time. This would have disturbed the velocity of the Feature development team as during that test time they cannot do Integration testing of their further developments.

So in our case Main is not 'Always Ready' for release, rather the QA/Test stabilization is done on Main and Development stabilization is done on Integration. Once Main is stabilised, we release a version and cut out a Release branch for future support.

When you said you have only 3 development branches, I thought I should ask you whether you are developing multiple features in one branch.

It is not necessary that you have only one feature being developed in Dev 1 or Dev 2, they can contain set of cohesive features (that can be built and delivered together) but please be careful that if you are developing multiple features in one Dev branch then again you are taking a risk where incompleteness of one feature can delay the release of the other complete feature. At release time, it is difficult to separate features in the same source branch. So take a wise judgement when deciding if multiple features are to be developed in one Dev branch. We have faced this problem and moved to One Feature - One Branch model to provide complete isolation of feature code.

Our process is as below -
  1. Develop in Dev branch
  2. FI from Integration branch (to have changes committed by other Dev branches and resolve conflicts locally rather than disturbing Integration branch)
  3. RI to Integration branch
  4. GET from Integration branch to Developer Integration test area/machine
  5. If succeeds, then RI to MAIN
  6. Test team performs GET and builds from MAIN.
  7. If test succeeds, MAIN becomes stable
  8. When it is time to release, just focus on stabilising MAIN and perform changes directly to MAIN if necessary. Once we make such changes FI the same to relevant Dev branches
  9. When MAIN is stable, release the version and cut out a release branch (e.g. Release 1.2.2) for future support.
  10. Do a FI from MAIN to Integration branch.
  11. At this point you can retire the old Dev 1/2/3 branches and delete them or can continue with them for future developments. It is recommened that you delete and create fresh Feature branches from Integration (e.g. Dev 4/5/6). However, if you choose to continue with Dev 1/2/3 then at this point you must perform another FI from Integration to Dev 1/2/3. You are also taking risks of any 'aborted' developments in these branches being retained in the branch which in future might sneak into the Integration branch.
For creating a new Integration branch and making it the parent of the Dev branches is easy. I guess you will figure it out by the tool docs. I believe the steps should be like
  1. Make sure all code in MAIN are checked in.
  2. Create an Integration branch from MAIN (it becomes a clone of MAIN).
  3. Assuming that the parent of the Dev branches are currently MAIN, Set the 'Parent' of the Dev 1/2/3 branches to Integration. It will not make any difference as Integration is currently a clone of MAIN.
You are now ready to go with the new hierarchy.

Hope this helps.

Please feel free to discuss/ask questions.

Rajarshi Basu Roy
Mar 13, 2014 at 7:10 PM
Yes, this is pretty similar to what we want to achieve.

However, my problem is the way to get there with branches already existing and with many differences between them.

Unfortunately, it is not possible to do as you suggest:
1.Make sure all code in MAIN are checked in.
2.Create an Integration branch from MAIN (it becomes a clone of MAIN).
3.Assuming that the parent of the Dev branches are currently MAIN, Set the 'Parent' of the Dev 1/2/3 branches to Integration. It will not make any difference as Integration is currently a clone of MAIN.
The new branch created under MAIN will not appear as choice in the re-parent dialog for the other dev. branches. You would have to perform baseless merges for that, but that's where we're getting scared mixing the wrong changes.

So, anybody has a better description of what has to be done to get there?