Appearance
Release guide
This guide explains how to get your code to development, staging and production, and how to do hot fixes.
We encourage everyone in the dev team to participate and initiate this process.
Index
Release to...
Hot fixes
Develop
To deploy to develop you create a PR on origin/develop (which is the default branch). For the PR you use the default PR template, where you need to explain to the reviewer what the PR is about, whether tests are added.
If the PR solves a story in shortcut, make sure to include the story number (SC-0123) in the PR title, so it's easier to create release notes later on.
Once your PR is reviewed and approved, you can merge it in develop. Upon merge, the develop branch will be deployed to dev.seamink.dev
Staging
To deploy to staging you create a PR from develop branch -> staging branch. For the PR you use the staging PR template, which contains a list of features and fixes that this release contains. This list should be an aggregated list of all the develop merges since the last staging release.
The PR can simply be named Staging release
Once your PR is reviewed and approved, you can merge it in staging. Upon merge, the staging branch will be deployed to staging.seamink.dev
Production
To deploy to staging you create a PR from origin/staging -> origin/master. For the PR you use the master PR template, which contains a list of features and fixes that this release contains. This list should be an aggregated list of all the staging releases since the last production release.
The name of the PR must be the next semver number (e.g. v3.0.1). We haven't yet defined rules for when a major or minor version change happens.
Once the PR is reviewed and approved, you can merge it in master. Upon merge, the master branch will be deployed to app.altruistiq.com
Tagging the release
Next up, you must tag the release using the same version number, and commit the tag to Gitlab. For the description of the tag you include the same release notes copy-pasted from the PR.
Announcing the release
The next step is to announce the release in Slack to the company. Head over to the #product-release channel and post the release notes there. Feel free to include a proper announcement and give kuddos, you can find examples in that channel.
The final step is to forward that message to the #general channel
Hot fixing production
To create a hotfix you branch of origin/master and make sure your branch name starts with hotfix/sc-1234/what-to-fix.
After making your fix, make sure all tests are passing, then create a PR and ask for review. Once your PR is approved you can follow the same process as releasing to production. As part of this process you want to make sure that the reviewer really tests your code, you don't want to take any risks breaking production!
Last make sure that when you create your release, you don't remove your hotfix branch just yet to make the back merge easier.
Back merging hot fixes
Hot fixes need to be back merged into develop, so all developers work with the latest code changes. Make a pr on origin/develop from your hotfix branch. Then follow the same process as for releasing to develop. Approval is not really required, as the code was already approved, so feel free to merge the fix yourself.