Hi,
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 -
Hope this helps.
Please feel free to discuss/ask questions.
Rajarshi Basu Roy
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 -
- Develop in Dev branch
- FI from Integration branch (to have changes committed by other Dev branches and resolve conflicts locally rather than disturbing Integration branch)
- RI to Integration branch
- GET from Integration branch to Developer Integration test area/machine
- If succeeds, then RI to MAIN
- Test team performs GET and builds from MAIN.
- If test succeeds, MAIN becomes stable
- 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
- When MAIN is stable, release the version and cut out a release branch (e.g. Release 1.2.2) for future support.
- Do a FI from MAIN to Integration branch.
-
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.
- Make sure all code in MAIN are checked in.
- Create an Integration branch from MAIN (it becomes a clone of MAIN).
-
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.
Hope this helps.
Please feel free to discuss/ask questions.
Rajarshi Basu Roy