Branching and merging strategy
Download as DOCX, PDF0 likes613 views
The document outlines a branching and merging strategy with the following key elements: 1. It defines a branching model with a single master branch containing stable code and separate branches for sprints, features, fixes, and releases. 2. It establishes naming conventions for branches based on the sprint, major/minor release, and feature number. POM versions will also follow this convention. 3. It describes workflows for creating branches from the appropriate source branches and merging code with pull requests and testing.
![[Final] best practices for access management (mule soft meetups riyadh) - j...](https://cdn.slidesharecdn.com/ss_thumbnails/finalbestpracticesforaccessmanagementmulesoftmeetups-riyadh-july2021-210724163604-thumbnail.jpg?width=560&fit=bounds)
Ad
More Related Content
What's hot (20)
Similar to Branching and merging strategy (20)
![[WroclawJUG] Continuous Delivery in OSS using Shipkit](https://cdn.slidesharecdn.com/ss_thumbnails/continuousdeliverywoss1-190403074306-thumbnail.jpg?width=560&fit=bounds)
Ad
Recently uploaded (20)
![Get & Download Wondershare Filmora Crack Latest [2025]](https://cdn.slidesharecdn.com/ss_thumbnails/revolutionizingresidentialwi-fi-250422112639-60fb726f-250429170801-59e1b240-thumbnail.jpg?width=560&fit=bounds)
Ad
Branching and merging strategy
- 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 ---