Skip to main content

Release flow

Preparing a release (end of sprint)#

Preparing a release basically create a new branch release/{name / version of the release}.

Name / version of the release#

The name of the release branch is {MAJOR}.{MINOR} for the next release. So for example, if develop is on 0.1.2 the next release version would be 0.2.0, so the name of the release branch is 0.2

Steps for preparing a release#

  • git checkout develop
  • git pull origin develop make sure you have the latest changes in your develop branch.
  • git checkout -b release/{MAJOR}.{MINOR - in example above 0.2, so: git checkout -b release/0.2;
  • npm version minor - in the above example this causes a version bump from 0.1.x to 0.2
  • git push origin release/{MAJOR}.{MINOR} - In the example above git push origin release/0.2.

Fixes on release/*#

Any needed bugfix on release/ (don't confuse them with hotfix which is only relevant for fixes for master) need to be done in a bugfix/ branch that is branched from release/. After implementing the fix, create a PR back to release/.

For the CODEOWNER/admin merging the bugfix PRs:

  • Merge all the bugfix PR's and test the result
  • npm version patch - in the above example this results in 0.2.1

Release to production#

  • Create a PR from release/{MAJOR}.{MINOR} with master as its base.
  • Merge the created PR. (DON'T DELETE THE BRANCH YET).
  • git checkout release/{MAJOR}.{MINOR} checkout the release branch
  • git pull origin develop Pull in the latest changes from develop
  • npm version minor update the version number
  • Create a PR from release/{MAJOR}.{MINOR} with develop as its base.
  • Merge the created PR. (You can safely delete the branch now).

Hotfix flow#

  • Start from the release branch (release/{MAJOR}.{MINOR})
  • Create a hotfix branch from a release branch (hotfix/optr-1234)
    • git checkout -b hotfix/optr-1234 release/{MAJOR}.{MINOR}
  • Add your fixes to the hotfix branch (commit them)
  • Push the hotfix branch to the remote
  • Create PR to release branch (PR1)
  • Create PR to develop branch (PR2) (only if you have no version conflicts - see below)
danger

Make sure that the version in package.json on the develop branch is and will remain one higher than in the release branch!
(e.g. if in release/0.2 the version is 0.2.x, then on develop the version in package.json should be 0.3.0)

If PR2 includes a version change that would decrease the version number on the develop branch (e.g. you've had other hotfixes on the release branch), do the following steps:

  • Switch to the develop branch (make sure that it's up-to-date by runnning git pull)
  • Create a new branch with the same name as the hotfix branch, but with an added -dev suffix
    (e.g. hotfix/optr-1234-dev)
    • git checkout -b hotfix/optr-1234-dev develop
  • Merge your changes from the hotfix branch into the new branch
    • git merge hotfix/optr-1234
  • You will get a merge conflict on the version field of package.json and package-lock.json - resolve it by accepting the version field that is on develop, or the one that is one higher than the version on the release branch.
  • Commit the merge (git commit)
  • Push the new branch to the remote
  • Create a PR from the new branch (hotfix/optr-1234-dev) to the develop branch (in this case this will be PR2)

In this case your git graph will look like this:

hotfix_flow_git_graph_version_conflict

  • npm version patch on release branch
  • push the release branch to the remote
  • merge PR1 (only after approved!)
  • merge PR2 (only after approved!)

hotfix_flow_git_graph