Releasing
- When do releases happen
- How to make a release
- Testing the release
- Publish the release
- Who has the release power
Releases follow a set weekly schedule. The release manager in charge will draft the release on Thursday, then it will be ready for testers to do their magic and give their approval. Then the release manager will usually publish and deploy on Tuesday in their local time.
- Create a New Release Issue.
Check for a Transifex pull request and merge it.
Download all current translations from Transifex with the Transifex client and add them to the master branch.
git checkout . to discard changes.
git checkout master
git pull upstream master
tx pull --force
git commit -a -m "Update all locales with the latest Transifex translations"
git push upstream masterAlso, as we're using GitHub Actions to manage deployments, we'll need to create a tag in advance, so testers can stage a release draft (before it is published):
git push upstream HEAD:refs/tags/vX.Y.Z
Draft a new release in the Github UI. Base the release on the newly created tag, pointing out the release version. This should correspond to the merge commit from the Transifex update. There's always a chance new PR's are merged between the draft is created and the actual release is published, so this makes the release consistent. Note, that the commit hash will only be visible once you save the draft: If you take a look at drafted release page, you should see the Transifex commit hash you just made in the steps above; Mouse-over it should display the message "Update all locales with the latest Transifex translations":
Collect a list of included changes in the release description. The quickest way is to use GitHub's Generate release notes button. If reviewers add the right labels to pull requests then the release note categories can be generated automatically. Otherwise you can refer to the old manual method.
Make sure the notes can be understood by humans. User-facing changes should appear first under their own headline, the list with other changes below. Mention any dependencies on ofn-install as well. Copy the user-facing changes to the #instance-managers Slack channel to let people know.
A lot of releases contain only minor bug fixes and tech updates. We then increase the patch version number (4.0.x). If there are significant user-facing changes, we bump the minor version number (4.x.0). The major number is only updated for very big changes like switching webserver.
All the steps above are summarized in the GitHub issue. Make sure you update it, accordingly and a link to the release draft itself into the release's Github issue so the release tester has a nice time ❤️.
Releases require some testing to ensure critical paths of the application keep working. Talk to one of the testers available to coordinate this (message in the #testing channel). Once the release's draft is finished and a tester is aware, one can stage the target commit via GitHub Actions, by clicking Run workflow by selecting the correct tag.
Keep in mind that any merges done to master while the release is in draft won't get tested (unless the release is redrafted with a new target commit and the new build is staged).
Wait for testers to give the ok to publish the release. Check the Testing the release section above for details.
Ensure the release was announced in #global-community (this should be automatically posted by the GitHub Slack app, after publishing the release).
Nudge the next person to release.
All Ha-Ri certified/core devs with server access will now do releases on a rotating basis.
We usually deploy a release for all instances on Tuesdays after publishing the release on Monday.
You can deploy to all production servers with:
ansible-playbook playbooks/deploy.yml --limit all_prod -e "git_version=[release tag]"
The first time you do this, you'll need to make sure that you can ssh into all the production servers without being prompted to confirm the authenticity of the host. I (Andy) did this by ssh'ing to each one and manually typing 'yes' at the prompt.
After you deployed, let the instance managers know so that they can run some basic tests. Include a link to the release notes page so that they can easily see what has changed. Post on #instance-managers slack channel:
@channel The new release has been deployed to all instances managed by the global team.
It's time for your after-deploy checks. You can see what was in the release here:
https://github.com/openfoodfoundation/openfoodnetwork/releases/latest