GIT Branching Strategy and Release Flow

From Tayledras
Jump to: navigation, search
GIT Branching Strategy and Release Flow

Development Workflow

  • Developer clones repository and checks out develop branch
  1. git clone [email protected]:corp-name/repo-name.git -b develop
  • Developer creates a new dedicated feature branch off develop in their local repo. Optionally, the name of the branch can include developer initials indicating who owns the branch
  1. git checkout -b feature/sprintX/MYTS-nnn-initials
  • Developer commits to create the feature. Developer can use interactive rebase to remove or squash unnecessary commits.
  • Developer makes sure that Jira ticket number is included as part of commit comments for every commit made.
  1. git commit -a -m "Add first commit of some feature for MYTS-nnn"
  • Developer pushes the feature branch to the shared TeachingStrategies Bitbucket repository.
  1. git push origin feature/sprintX/MYTS-nnn-initials
  • Developer files a pull request via Bitbucket
  • Developer can create the pull request through their Bitbucket account by navigating to their forked repository and clicking the Pull request button in the top-right corner. The resulting form automatically sets developer’s repository as the source repository, and it asks them to specify the source branch, the destination repository, and the destination branch
  • The rest of the team reviews the code, discusses it, and alters it
  • The pull request initiator rebases the code based on develop after the code review is complete and resolves conflicts before starting the merge process into int-develop and later develop branch
  • Any conflict resolution added should also be reviewed within the pull request before merging the branch into int-dev branch
  • After validation, developer marks the commit as “Ready for develop”
  • Developer merges the feature into the develop branch

Release Workflow

  1. At the start of every sprint, Dev creates feature branch as described in development workflow
  2. Developer sets the Jira ticket from “In Requirements” to “In Dev” and starts development.
  3. After feature is complete, Developer deploys the feature branch to local environment
  4. Developer runs manual validation tests to conform requirements
  5. Developer tags the commit as “Ready for Develop”

INT-DEV

  1. Developer creates a Pull Request using “Ready for Develop” commit and goes through Code Review process
  2. Developer merges Feature branch into 'Integration Develop (int-dev)' branch
  3. Manual CI build deploys latest INT-DEV changes to DEV environment
  4. Developer performs manual testing on int-dev branch

DEV

  1. Developer sets the Jira ticket to “In Review”
  2. Developer creates Pull Request and goes through Code Review process
  3. Developer merges Feature branch into 'Develop'
  4. Automatic build gets triggered and deploys to 'DEV' environment
  5. Automated tests runs on DEV environment.
  6. Developer marks work item in JIRA as 'Ready for QA'
  7. Developer/Qa team (manual or automated) tags commit-id with QA tag

QA

  1. Developer/Qa team creates 'QA' tag for all work items which QA ready
  2. Developer/Qa team triggers 'QA' builds in Jenkins using 'QA' tag and commit-id that was tested in DEV
  3. Qa team performs 'QA' testing and marks it as 'QA DONE' in JIRA
  4. Developer deletes local and remote feature branch for the specific feature

INT

  1. Developer/Qa team merges 'QA' tagged commits from 'develop' to 'release/v1.0' branch
  2. Developer/Qa team creates 'INT' tag on the release/v1.0 branch
  3. Developer/Qa team triggers 'INT' build using the 'INT' tagged commit
  4. Business Users/Performance Testers perform UAT/Performance testing on 'INT' environment
  5. All UAT issues are reported through a new JIRA defect

PROD

  1. Developer/Qa team creates 'PROD' tag on 'INT' passed commits
  2. Developer/Qa team triggers production release pipelines (gated approvals) using the change management approval process.
  3. Once production deployment is complete, Dev/Qa team will merge the 'release/v1.0' branch to 'master' and tag it

HotFix

  1. The “hotfix” branches will be used to quickly patch production releases. Hot-fixes branches will be created from the 'master' branch using the release tag. This is the only branch that should fork off master.
  2. Once the fix is ready, it will be tested on “integration” or closest production like environment and deployed to Production using standard INT->PRD workflow.
  3. Once the fix is complete, it should be merged back to master and any applicable downstream branches like ‘develop’. The commit should also be tagged in master branch.

Deployment Day

  • Release-x is deployed to production and merged into Master
Retrieved from "https://tayledras.com/wiki/index.php?title=GIT_Branching_Strategy_and_Release_Flow&oldid=836"