Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- This document describes how our code changes make it from our IDEs to production. This includes managing changes in JIRA and code in Git. The plan is inspired by both [GitFlow](https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow) and [GitHub Flow](https://guides.github.com/introduction/flow/).
- ## Master and develop branches
- Each of our git repos has two branches that we never close: master and develop.
- The master branch contains our production code. When we merge code from release and hotfix branches to master, we deploy them immediately to production. Master’s commit history tell of releases.
- As we finish developing new user stories and bug fixes, we merge them back into the develop branch. We immediately deploy these changes to our test environment. We merge feature branches into the develop during the first seven days of the sprint.
- 
- ## User stories and bug fixes
- We create a feature branch for each new user story and bug fix. This allows us to isolate the progress until it is done, and we merge it back into development period.
- 
- ### New user stories and bug fixes steps
- During development period, we do the following steps in git and JIRA.
- 1. When we start work on an user story or bug, we
- 1. Transition the JIRA issue from OPEN to DEV IN PROGRESS
- 1. Create a feature branch from develop branch, using the following naming convention: feature/JIRA ID
- 1. Commit changes to the feature branch. For the commit message we can have the following convention: JIRA ID: JIRA task title. If any subsequent commits are needed, we could use the same convention but add a short description of the fix: JIRA ID: JIRA task title - short description of the fix
- 1. When the change is ready for code review, we
- 1. Transition the JIRA issue from DEV IN PROGRESS to CODE REVIEW
- 1. Create a pull request with the JIRA issue ID as the name, and two peers assigned as reviewers
- 1. Review the pull request and update the feature branch accordingly
- 1. If the code review is more than 500 lines of code or will need more than one hour, the responsible have to allocate time and guide the reviewer through it as peer programming.
- 1. When the developers have approved the pull request,
- 1. Squash and merge the pull request into the develop branch and close the feature branch
- 1. Manually run the migrations in development databases that are not automated by CI
- 1. Confirm that CircleCI deployed the change
- 1. Transition the JIRA issue from CODE REVIEW to READY FOR QA
- ## Releases
- We create a release branch for each release. We do this on the seventh day of the sprint, when we are ready to regression test the release. When the release branch is opened, a deploy will be made to a staging server from this branch. When bugs are found in the release, we fix them in the release branch, and test them on the staging server. Assuming the release is ready at the end of the sprint, we merge it into master and develop and tag master with a version number. At that point any last-minute changes made on the release will also be available on the develop branch.
- 
- ### Release steps
- Our process for creating, testing, fixing, and deploying a release are explained below.
- 1. End of day 7
- 1. Developer creates and merges (squash and merge) pull requests to the development branch for any outstanding features slated for release at the end of the sprint
- 1. Developers DO NOT merge any code not slated for release at the end of the sprint
- 1. Day 8, 9, and 10
- 1. QA tests and creates JIRA issues for each new bug discovered
- 1. Developers fix bugs in new branches that will be reviewed and squash and merged in the development branch, at which point fixes end up on staging server
- 1. Developer creates a release branch after all features and bugs are QA Done. For example, "release/s30".
- 1. After release branch is created, new features can be merged in to development.
- 1. Day 12 - Deploy
- 1. Developer merges (normal merge) release branch into master and develop
- 1. Developer creates a release tag in master. For example, "release/s30".
- ```
- git tag <tagname>
- git push origin <tag>
- ```
- 1. Developer deploys to production
- 1. Developer notifies product managers and testers
- 1. Testers verify the critical features and integrations
- 1. Developer who worked on JIRA issues transitions them from QA DONE to DONE and notify stakeholders
- 1. Product manager notify stakeholders
- ## Hotfixes
- Hotfixes are necessary when we need to fix code in production between scheduled releases. Hotfixes are made in a hotfix branch, which work similarly to release branches.
- 
- ### Hotfix steps
- 1. Developer creates a hotfix branch off of master, with the branch name "hotfix/..."
- 1. Developer commits fix the the hotfix branch and creates pull request
- 1. Developer posts the pull request to the #engineering Slack channel, with a scheduled deployment time, instructions for testers, and justification for the hotfix.
- 1. One or more other developers review code and accept the pull request
- 1. Developer merges code into the develop branch
- 1. Testers verify the fix using the test environment and move issue from XXX to YYY
- 1. Developer merges pull request into master
- 1. Developer deploys to production
- 1. Developer notifies product managers and testers
- 1. Testers verify the critical features and integrations
- 1. Product manager transition JIRA issues from QA DONE to DONE and notify stakeholders
- 1. Pod conducts postmortem and posts to the #engineering Slack channel
- ## Terms
- Term | Definition
- -----------|-----------
- Hotfix | unplanned change to production code that must happen before a release
- Release | version of code for sprint that requires regression testing and UAT (release branch)
- Bug | bug to be planned and fixed during an upcoming sprint
- Regression | bug found in a release candidate that blocks deployment
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
