Branching and merging strategy under DevOps + Agile environment

1. Page 1 of 4
Branching & Merging Strategy.
Date 19th
Dec 2016
Author Rahul Janghel
Version 1.0.0
1. Objective:
Build a better Branching and merge policy which will provide:
1.1 Single Master model with :
 Stable and Clean Master Branch.
 Release-ready code on Master Branch.
1.2 Defined Branch-forking practice.
1.3 Predictable :
 Sprint / Feature Branch Name
 POMVersion
 Branch for Feature / fix Release, along with feature / fix release sequence.
 Source branch to fork a feature / fix branch
 Destination branch to receive feature / fix.
1.4 Independent branch per :
 Sprint
 Feature
 Fix.
1.5 Stable upstream branch.
2. Define Branching Architecture :
2.1 Branch Naming Convention :
<Sprint Version>.<Major Release>.<Minor Release>.<Feature / Fix Branch>
- Sprint started at 1st Oct 2016 may have a Sprint Version as 2016_Q4.1.0
- Sprint Version could be anything between 2016_Q4.1.0 to 2016_Q4.9.99
- Branch Version will be always an incremental number.
- Week number of calendar month will not get consider.
2.2 Sprint and release branch naming convention:
- Create Sprint Branch with name “2016_Q4.0.0” in sprint period of “2016-Q4”.
- Branch Naming Scheme under Sprint “2016-Q4” :
 1st major release : “2016-Q4.1.0”
 1st minor release under 1st
major release : “2016-Q4.1.1”
 2nd major release : “2016-Q4.2.0”
 1st minor release under 2nd
major release : “2016-Q4.2.1”
2.3 Feature branch naming convention:
- In sprint period of “2016-Q4”, Developer shouldcreate feature / fix branch name as
“2016_Q4.0.0-feature_number”.

2. Page 2 of 4
- Feature Branch Naming Scheme under Sprint “2016-Q4” :
 Feature / fix branch name under 1st major release:
“2016-Q4.1.0-feature_number”.
 Feature / fix branch name under 1st minor release :
“2016-Q4.1.1-feature_number”
 Feature / fix branch name under 2nd
major release:
“2016-Q4.2.0-feature_number”.
 Feature / fix branch name under 2nd
minor release :
“2016-Q4.2.1-feature_number”
2.4 Release Branch naming convention:
- For Sprint period “2016-Q4”, Release Branch name should be :
 “2016_Q4.0.0_RC”
2.5 POM version convention:
- In sprintperiodof “2016-Q4”, POMversioningshouldbe like, (If using SNAPSHOT) :
 1st major release branch POMVersion : “2016-Q4.1.0-SNAPSHOT”
 1st minor release branch POMVersion : “2016-Q4.1.1-SNAPSHOT”
 2nd major release branch POMVersion : “2016-Q4.2.0-SNAPSHOT”
 2nd minor release branch POMVersion : “2016-Q4.2.1-SNAPSHOT”
 Feature / fix branch POMVersion under X major & Y minor release:
“2016-Q4.X.Y-feature_number-SNAPSHOT”.
 For Release Branch “2016_Q4.0.0_RC” POMVersion : “2016_Q4.0.0”
2.6 Release Branch Tag name scheme :
- For Sprint period “2016-Q4”, Release Branch “2016_Q4.0.0_RC” should get tag as
 “2016_Q4.0.0_RC_Release-Date”
3. Branching Process flow :
3.1 Sprint Branch creation work flow :
- Ensure Master Branch has all updates from last Sprint Release Branch.
 Check master branch has same commit ID as last Sprint Release Branch.
 Last Sprint Release Branch is tagged after successful Production / QA / QA
release.
- Create ticket / send mail to DevOps team to create a Sprint branch from master.
- Update Sprint version in all POMfiles.
- Ensure approved naming scheme is followed for branch creation and POMfiles.
- Execute Integrationtest,code coverage shouldmeet minimum passing percentage.
- Inform all developers upon new Sprint branch status.
 Mention new branch’s name.
 POMfile version
 Suggest name of first feature branch for current sprint.

3. Page 3 of 4
3.2 Feature / Fix Branch creation work flow :
- Create ticket / send mail to DevOps team to create a feature branch.
- Ensure Feature Branch has been created from sprint branch.
- Update feature branch POMversion in all POM.xml files.
- Ensure approved naming scheme is followed while crating feature branch and
updating POMfiles.
- Inform all developers upon new feature branch status
 Mention new feature branch’s name.
 Feature Branch POMfile version
3.3 Release Branch creation work flow :
- Call for Code Freeze 2 days prior to Production / QA / QA Release.
- Insure all feature / fix branch is merged to Sprint Branch.
- Take a signed off from QA team on existing fix committed in Sprint Branch.
- Create ticket / send mail to DevOps team to create a Release branch.
- Ensure all POMfiles is following approved naming scheme for POMversion.
- Ensure direct commit to Release Branch is blocked.
4. Branch Merge Process flow :
- Ensure Master and Sprint Branch is protected from direct Commit.
- To update Sprint branch from feature branch, create a pull request.
- Onlyaftersuccessfullypassingcode review criteria,merge buttonshouldgetenable.
- For Production / QA / QA / QA release, create ticket / send mail to DevOps team to
merge Master Branch into Release Branch.
- Ensure all POMfiles is following approved naming scheme for POMversion.
- Run all unit test and Integration test suite on Release Branch.
- Use Release Branch artifacts for Production / QA / QA / QA Release.
- Ensure Production/QA / QA / QA environmentissuccessfullydeployedfromRelease
Branch.
- Tag Release Branch.
- Create ticket / send mail to DevOps team to merge Master Branch into Release
Branch.
5. Use of Branch to Deploy on various environment :
- Use Sprint Branch to Deploy on QA / Dev environment.
 At least once every day.
- Use Feature / Fix Branch to deploy on Dev environment.
 Multiple time or as require every day.
- Use Release Branch to deploy on Staging / UAT / Preprod environment.
 After code freeze
 Before Production / QA / QA release.

4. Page 4 of 4
6. Release Branch update flow (Post Code Freeze) :
- Ask Developer to create ticket / send mail to Sprint Owner, seeking approval.
- Attach Unit test report along with request.
- Open Pull request for code review and merge into Release Branch.
- Run all unit test and Integration test suite on Release Branch.
- Use Release Branch to deploy on Staging / UAT / Preprod environment.
- Merge Release branch into Master branch.
7. Production / QA / QA Release & Hot fix Deployment :
- AfterregresstestingonUAT & Preprodenvironment,share reportswithBA & Sprint
Master and take signoff.
- Use Release Branch artifacts to Deploy over Production / QA / QA Environment.
- In case of any bug/ issue /hotfix release, from Master branch create new branch as
 For 1st major release : “2016-Q4.1.0”
 For 1st minor release under 1st
major release : “2016-Q4.1.1”
- Use fix branch artifacts to Deploy over UAT / Preprod Environment and verify.
- Use fix branch artifacts to Deploy over Production / QA / QA Environment.
- Merge fix branch into master branch & next Sprint branch.
--- EOD ---