Git branching strategies for CICD

Question

Just looking for thought on below branching strategies keeping CICD in mind.

1. Master branch -

   1.1 Development branch - Fork from master

     Team A branch - Fork from Development branch and merge to development branch after feature implementation for QA/Integration testing Team B branch - same as above 1.1.1 Release branch - Goes in PROD 

Once Team A and Team B branch merge and QA verification done, create release branch and have Final regression on it. This release branch will go to Production.

Then merge Release to master branch.

Intent -

1. Master branch is stable and production running code is available in it.

2. Team branch can deployed on DEV environment and have required CICD configuration on server.

Any issue with this approach?

Answer 1

That's not true CI (by CI I mean development strategy, not tooling) because you have team branches meaning the teams' work is not integrated until merged into master - there are always teams whose work is not visible to other teams and which doesn't see work from other teams (thus open to the rebase/merge hell ).

For true CI strategy all teams would work on master (if really pulling task branches they'd be merged back into master very fast, not more than a few days lifespan) - everybody is practically on the same page.

A CI tool (and maybe a CD tool in a staging environment) would keep an eye on master health.

Whenever master is current release -ready or when changes for the next release start colliding with the current release (release divergence) the current_release branch is pulled and will never be merged back into master (such merges would be a big problem due to release divergence). Any bug fixes in current_release (if applicable to master as well) would be cherry-picked and double-committed (just because a fix is OK on one branch it doesn't mean it's OK on another branch).

The current_release branch is practically your production branch. It needs it's own CI/CD setup, tailored on the current release features. Production builds are just labels on this branch.

The master branch continues to evolve towards next release .

Rinse and repeat.

You can also have further sub-branches of current_release for multi-level releases (major/minor/etc), which are also never merged back into their parent branch. The relationship between each such sub-branch and its parent is exactly as the relationship between current_release and master .

Answer 2

To truly being doing CI (and CI is required to do CD) you would merge to master very regularly and not have long lived feature branches. I believe that once a day is expected for it to be "CI".

An alternative approach to the one you suggest is to have short lived developer branches for daily work. Then to have a deployment pipeline that moves each code change through a series of test stages. Only once the changes have passed each stage will they go to the next stage and be ready for production. This allows you to work on master but to remain stable and only allow passing code to enter production.

To deal with independent feature work you can use feature toggles instead of branches. You can toggle features on and push to master to test them and deploy if all is well. If not, or if there is a business need to remove a feature, you can toggle off the feature and continue to use master safely. I have seen this work very well on two products I have worked on.

I know this is very simplified but it is just to make a suggestion of alternatives for you and hopefully to help. You can learn more about implementing these techniques on a bunch of blogs and stackoverflow answers - http://martinfowler.com/articles/feature-toggles - http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf - Feature Toggles vs Feature Branches