Branching & Merging Strategy— A handmade hardened template!!
We are at the end of an eventful year (possibly for all wrong reasons), but as Churchill said not to let a good crisis go waste, hope all have made the best out of 2020!
Branching and merging strategy is preamble to GitOps. Yes, unless we have the right mix of clarity and vision towards the flow of our code, by multiple dev teams for a multi-tier/multi-component application, GitOps would be a distant dream!
So it becomes absolutely important for a solution architect to consort with DevOps program architect to design and implement an effective branching & merging strategy around the policies and processes of the project.
When it is done right, at the very beginning of the project allowing developers to adapt it from the Sprint 1, we can avoid technical debt & overhead later.
So meticulous planning becomes the intricate part of the whole game. This cumbersome & painful planning process running against time can only be eased when we involve DevOps right at the RFP stage.
Ok, to reiterate, advocating branching and merging strategy to be implemented right from the Sprint 0, imagine the amount of work that needs to be done beforehand- like deciding on the composition of Dev team, their location, their speed, choice of TLs & SME, deciding on onboarding of QA team and their need of pipelines, number of environments, deciding on sprint length & release cycle, number of active components in the application that needs development form the day one, factoring in developmental work after few sprints.. list is endless. To facilitate and advocate the importance of having an effective branching & merging strategy right from the Sprint 0, DMs & CPs should be looking at involving DevOps during sales pitch and bake the outcome in SoW. (Of Course this is one such case where am advocating inclusion of DevOps during Sales pitch)
Alrighty, let's assume in a given project, the program architect has been successful in collaborating with DevOps architect in bringing out a perfect blend of branching & merging strategy. This has been heavily customized & rightly sized, according to the needs of dev/test/SM/PM. Ultimately everyone is happy and here is the sample strategy that I would like to put and explain different scenarios.
Pic below shows 3-Branch Git-Flow strategy where we have highly active & highly unstable ‘Develop branch’ which serves as the source for the other two branches. Once the Dev SME gives a go ahead on each feature merge by each of the feature branch, a PR merges (3-way merge) the code in Dev to ‘Release branch’. This Release branch can be aptly named to suit the release version of the project currently in. Once the QA passes many such Dev merges within a sprint, they pop a ‘release candidate’ at the end of the sprint which is now ready to be deployed to non-prod. Once the business approves the code on non-prod, a PR merges (FF merge) release branch to main which is now ready to be deployed to PROD.
So, it’s a happy flow. What happens if a bug gets identified by QA? What happens if a bug is reported out of PROD?
Below pic explains how a bug is tackled at QA stage. Since its a QA stage and still we don’t have our code in PROD, this takes the same route as feature except that the feed to Dev branch is now from a bug-fix branch. This flow is guided, controlled & monitored by a defined workflow in an ALM tool.
Bug in PROD is tackled by carving out a hotfix branch from the main branch. Since it’s a P1 incident, it gets worked on priority and gets directly merged (FF merge again) to main branch. Pic below shows the same.
Well, I hope I made it clear on the branching strategy which I have successfully implemented across projects, hence a hardened one! It’s more than just words, so please do comment on any questions you have. Until then stay put, stay safe, and yes Happy new year- 2021!!
