Branching Strategies for CI/CD

A branching strategy is an agreement, or a defined set of rules, that describes when and why branches are created, the naming convention, the purpose of particular branches, and so on.

In the current market, Git is the most popular source control version available. Every organization using Git has some standard of Branching Strategy for the team to deliver a quality solution. There are lots of branching strategies with pros and cons and the standard is maintained by an organization to organization differently. So you are free to implement globally recommended or custom branching strategies as per your need. In this article, I have posted the branching strategy which I am using in my organization for one of our microservices-based applications as devops process.

Want to know mostly used GIT commands, kindly check Useful git commands with examples

Legend

1. A new branch is created from the latest source code
2. Deploy from active development (integration) branch to QA environment
3. A new feature branch is created 
4. Deploy from feature branch to Sandbox environment
5. Merge feature branch into sprint branch 
6. Deploy from sprint ahead branch to Sandbox environment
7. A new bug fix branch is created 
8. Merge bug fix branch into sprint branch 
9. Merge from the active sprint branch into the master branch
10. Deploy from the master branch to the UAT environment
11. Merge from active sprint branch into sprint ahead branch
12. A new release branch is created 
13. Deploy from the release branch to the Prod environment
14. Production bug fix branch is created 
15. The production bug fix branch is merged into the release branch 
16. Deploy release branch to QA or Sandbox environment 
17. Merge from the release branch into the master branch 
18. Merge from the master branch into the active sprint branch

Life cycles 

Sprint

• Active development
  1. Sprint branch (sprint/N) is created from the latest version of the code (step 1)
  2. Latest sprint code is deployed to the QA environment for testing (step 2)
  3. New features (step 5) and bug fixes (step 8) are merged into an active sprint branch via PR and code review
• Code freeze
  1. No new features are merged into the sprint branch, only critical bug fixes (step 8)
  2. New sprint ahead branch (sprint/N+1) is created from the active sprint branch (step 1)
  3. Active sprint is deployed to QA environment (step 2)
  4. Sprint ahead branch is deployed only to Sandbox environment (step 6)
• End of sprint / demo
  1. Active sprint branch is merged into master branch (step 9)
  2. Master branch is deployed to UAT environment (step 10)
  3. Active string branch is merged into sprint ahead branch (step 11)
  4. Active sprint branch (sprint/N) is dropped and sprint ahead (sprint/N+1) becomes active branch
  5. New active sprint branch is deployed to QA environment

Feature

1. New feature branch is created from latest version of the code for each new feature implementation (step 3)
2. If dev testing is required on real environment, feature branch can be deployed to Sandbox environment (step 4)
3. When implementation is completed, code should be merged into active sprint branch via pull request and code review (step 5)

Bug fix 

1. New bug fix branch is created from latest version of the code for each new bug fix (step 7)
2. When fix is completed, code should be merged into active sprint branch via pull request and code review (step 8)

Release

1. When all sprints are completed, new release branch (i.e release/1.0) has to be created (step 12)
2. Release branch is deployed to Prod environment (step 13)
3. There is only one active release branch at each point of time. If new release branch (i.e. release/1.1) is created, previous becomes inactive and remains only for history purpose

Release bug fix 

1. New bug fix branch is created from active release branch (step 14) 
2. When fix is completed, code should be merged into active release branch via pull request and code review (step 15)
3. Active release branch is deployed to QA or Sandbox environment for verification (step 16)
4. When fix is verified:
   1. Active release branch is deployed to Prod environment (step 13)
   2. Active release branch is merged into master branch (step 17)
   3. Master branch is merged into active sprint branch (step 18)