Branching Strategy

After several iterations and many future iterations to come, we decided to come up with a feature-based release branching strategy that works for the team.

This guide highlights how we are going to do the feature-based release process and how the branching works to support the feature-based release. Based on the branching, the teams impacted will be

1. Development — How to create the feature branches, how to merge the changes
2. QA — Testing strategy will be based on the branching and prioritization
3. UX — Where to review the UX changes for a feature
4. PO — Prioritizes the features, Monitors progress of features, Accepts the stories completed for the feature

Step-by-step guide

The below instruction guide illustrates the feature-based release strategy that our team will follow if we are following this feature-based releases. This strategy has been inspired and implemented similar to the article that has been defined in the link below:

https://nvie.com/posts/a-successful-git-branching-model/

https://medium.com/@sairamkrish/git-branching-strategy-for-true-continuous-delivery-eade4435b57e

Based on the published branching process, there have been few alterations made to match and keep a few of the existing practices that have helped us to deliver production pushes in the past. The below diagram illustrates the feature-based branching that has been proposed.

Detailed Explanation of the branching is as follows:

The central BrightLab repo for all microservices holds four main branches with an infinite lifetime:

• master
• staging
• qa
• feature

Production Branch / Main Branch

The master branch at origin should be familiar to every developer. Parallel to the master branch, other branches exist called origin/qa and release/staging. We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state and then a branch is tagged with a release number.

• The staging branch is branched out from release/V2Base. All releases are parked here for automation testing and demo.
• Feature ready for deployment and already notified to users in the staging branch is merged into master.
• Hotfix branches are created from the master branch and deployed to the staging branch. Upon successful validation of the hotfix, the hotfix branch is merged back to master. Feature branches are again rebased/merged with staging to include it for the upcoming features.
• The master branch is protected so that no direct commit can be done by anyone against this branch. Only Priyank, DevOps, and Santhamohan can access this branch

Feature Branch

Unlike the main branches, these branches always have a limited lifetime, since their life span is limited to the feature development.

• Any new feature is branched out from staging
• Feature development happens in the feature branch(s)
• Each feature UI branch will be mapped to the feature UI server
• Both feature the UI server and the QA server is mapped to the same development backend server. This is due to a lack of cloud environments.
• Feature branch has just staging + this feature related commits
• If some other feature got released while this feature is still in development, the developer needs to rebase/merge with the staging. Else he won’t be able to merge it to QA.
• Once the feature is developed and stories are accepted by QA, it is merged into the QA branch for testing.
• Further development on the feature branch is prohibited by locking the feature branch.
• No two feature branches will be merged together and merged into any upper branches.
• Same feature branch will be merged to QA, staging, and master
• Development team owns this branch but postcode freeze, it is locked as mentioned earlier

qa Branch

We consider origin/qa to be the “integration branch” and will be literally The lead will create pull request from the feature branch to qa branch for an end to end testing. This is where any automatic Jenkins builds are built and deployed directly to the QA cloud server. If there are any issues identified, the issue has to be fixed in the respective feature branch and pushed back to QA for revalidation. Since developers are disciplined to fix all issues in the feature branch and move to QA branch, there should be ideally no surprise bugs in the QA environment. When the code deployed in the QA reaches a stable point and is ready to be released, all of the changes from the feature branch should be merged back into release/staging. How this is done in detail will be discussed further on.

Staging Branch

This is the branch where QA will perform automation script execution and all the pre-production validation/regression testing is done. The code from this branch will be deployed to the Staging cloud cluster. All the features validated completely in the QA environment will be parked in staging and subsequently rebased with the respective feature branches.

It’s not Perfect but Hope this helps anyone :) Merge conflicts are a pain.