-
Notifications
You must be signed in to change notification settings - Fork 5
How to release apollo
- Set up a release branch and bump versions
- Merging to main will trigger a git tag and a docker image build (there is no npm release)
- Raise PRs in
deploymentto update staging and prod
You'll need to decide whether we need a release branch to assemble the release.
Usually you DO want this: a branch called release/next or release/1.2.3 is the best way to organise multiple PRs into a single place and handle version bumps and final testing before merging to main. This is the best way to organise a clean, professional release.
If you are creating a release branch, the PR description should summarise the features going into that release. The commit history should reflect this. Detail isn't needed, just the headlines.
If you're just releasing a patch from a single PR, it's OK just to releases straight from the fix branch.
Whatever branch you're releasing from will be known here as the "release branch"
All changes on the release branch must include a changeset
Run bun changeset version to convert changeset in to the correct version bump and generate changelogs (you can also do this manually but changesets are cool and merged PRs should include them)
Check the diff to make sure the changelog broadly covers everything and that the version looks correct (ie should it be a major?)
When you're happy, commit changes and push to github.
Next we need to merge the release branch to main which will publish the docker image.
Make sure tests are passing.
The release branch may need a review approval before it can be merged - but at that point anyone should be able to merge it. Admins can override this and merge directly.
Merge the release branch to main to trigger tagging and docker image building.
Once the Docker image is ready, it needs to be deployed.
Open a PR on the deployment repo and set the correct versions in the apollo.yaml files. See this example. Assign Rory for review, but maybe also shout out on slack.
You should first deploy to staging, then give it a smoke test, then raise a PR for prod. You may wish to open both PRs at once but mark the prod one as draft until staging has been tested.