-
Notifications
You must be signed in to change notification settings - Fork 33
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
41 additions
and
77 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,98 +1,62 @@ | ||
# Releases | ||
|
||
There are three types of Renku releases: Sprint release, Hot/bug fix release and Quick release. | ||
There are two types of Renku releases: planned and unplanned. | ||
|
||
## Sprint release | ||
A release consists of: | ||
|
||
A sprint release is planned on the Tuesday after the end of every sprint | ||
(every three weeks). | ||
The current state of the main branch is released as is, only checking the | ||
wording in the changelog to ensure it is of good quality and adding the version | ||
information. | ||
* Helm chart changes to reflect the new versions of individual components | ||
* Changes to `CHANGELOG.rst` | ||
* A new tag in this repository, which results in packaging and pushing out new helm charts and corresponding docker images | ||
|
||
### Update components [Graph, UI, RP] | ||
This procedure should be followed for *any* release: | ||
|
||
🧑🏭 Component maintainers can tag a release in their local repositories whenever | ||
they want, the schedule is up to them. They are responsible for updating the | ||
`CHANGELOG.rst` file in the auto-PR in the Renku repository. | ||
Please create a new section above the last release if no one has already done it. | ||
Please follow the `CHANGELOG-template.rst` for formatting and ordering the changelog. | ||
The auto-PRs **must** be merged with an updated changelog/release notes. If upgrading | ||
a service will knowingly result in an extended outage (e.g. because of a DB migration) | ||
this *must* be clearly noted and highlighted in the release notes. Use emojis freely. | ||
Make sure YAT is aware of any expected complications and plan to be involved in | ||
the rollout process. YAT and the product team have to approve those PRs before they | ||
can be merged, so changes and the changelog are double-checked. | ||
* Create a release branch (e.g. `0.46.x`), if one does not already exist, with the [release action](https://github.com/SwissDataScienceCenter/renku/actions/workflows/create-release-branch.yml). | ||
* Create a `CHANGELOG` entry for the release and open a PR; create a deployment, this is the reference for the release. | ||
* Note that any PR that should go into the release needs to target the release branch _not_ `master`. | ||
* All release branches should be protected. | ||
|
||
🧑🤝🧑 If two components need to coordinate for a release (e.g. new version | ||
of Graph needs new version of RP), they should combine their auto-PRs and | ||
merge them in a single go. Generally, components should strive to keep | ||
dependencies between them to a minimum and coordinated component releases | ||
should not usually be required (using API versioning, feature flags etc.). | ||
Acceptance tests have to pass on all release branches before merging. | ||
|
||
⚠️ If a component turns out to be faulty, please revert to the previous version | ||
as soon as possible to prevent accidentally including it in the next Renku release. | ||
The sprint release DOES NOT wait for a fix. | ||
If a regression made it into a release, remember to add an acceptance test to | ||
prevent this from happening again. | ||
## Planned release | ||
|
||
🕛 The deadline for this is Tuesday morning after the sprint. Please be on time! | ||
A release is planned either at the beginning of a build cycle or at the start of the cooldown period. | ||
Depending on the features being developed, there may be more than one release per build cycle, especially | ||
if a feature requires significant infrastructure changes. | ||
|
||
For larger features that require the coordination of several teams, consider using | ||
a feature branch to which the individual component updates can be merged. This feature | ||
should then get merged into the release branch once the feature is complete. | ||
|
||
### Tag a release [Product team] | ||
Note that there might be multiple planned release branches and PRs active at the same time. | ||
|
||
🛳️ The product team updates the `CHANGELOG.rst` file when needed to make it more | ||
user friendly and potentially highlight relevant features or disrupting changes. | ||
This process can start on Tuesday after 12:00. As soon as the release PR is merged, | ||
the product team tag a release and inform YAT for the rollout. | ||
## Bugfix release | ||
|
||
The procedure for a bugfix should be more or less the same as for a planned release. If a branch already exists for the | ||
correct *minor* version, e.g. `0.46.x` for a release `0.46.0`, start from that branch to create `0.46.1`. Care must | ||
be taken to rebase or cherry-pick any relevant additions from `master` into that branch. Do not rush this and please | ||
communicate with others on the team to make sure we are not a) accidentally releasing new things with a bugfix and b) | ||
slapping together incompatible changes. | ||
|
||
### Deploy [YAT] | ||
Once the bugfix is merged to `master`, make sure that it can propagate seamlessly to the other currently active release | ||
branches. | ||
|
||
* Before _any_ rollout is done, consider whether any of the upgrades will result in a longer-than-normal outage. If yes, create appropriate maintenance windows marking specific components as affected. Coordinate maintenance windows with external Renku deployments admins (UniFR, SV). | ||
* Roll out the release: one PR per deployment is automatically created in the `terraform-renku` repository to update the version. Make any needed configuration changes to the PR. Approve and merge the PR to deploy. Important: if needed, add the `scheduled maintenance` label to help avoiding it being merged too early. Limited should be rolled out before Renkulab, as a canary release (see below). | ||
* Limited should be rolled out ~1 week before the Renkulab rollout, to give a chance to find bugs early. E.g. Limited on Wednesday and Renkulab on Monday. | ||
* Make the tag in the `renku` repository, monitor the automatic process of chart publishing and deployment on staging. | ||
* Merge terraform-renku PR, monitor Flux upgrading Renku everywhere. | ||
* After the Limited and RenkuLab deployments are completed, notify the Product team that the deployments are live, so they can post the release Highlights. | ||
|
||
### Share Release Highlights [Product team] | ||
* On Wednesday with the Limited release, share release highlights with SDSC (Slack). | ||
* On Monday with the RenkuLab release, highlight prominent changes on Discourse, Twitter, and other channels. | ||
|
||
|
||
## Hot/bug fix release | ||
|
||
This is an unplanned release. It happens when a component has a bug that needs an **immediate** fix and rollout. | ||
In some cases the fix might be deployed in place before a proper release is made. | ||
|
||
### Pre-requisites [Graph, UI, RP] | ||
## Maintenance PRs | ||
|
||
Announce as soon as it is needed. | ||
Maintenance PRs (e.g. library updates) should generally target the next release branch. | ||
|
||
* Create a Pull Request in the `renku` repository and update the `CHANGELOG.rst` file. | ||
Ask the Product team for a review on the PR in Renku repository and tag the new release. | ||
* A Pull Request in the `terraform-renku` repository is automatically created to update the version. Make any needed configuration changes to this PR. | ||
* Approve and merge release Pull Request, tag new release. | ||
## Make the release [Product team] | ||
|
||
### Process [YAT] | ||
🛳️ Once the work on the release branch is completed: | ||
|
||
* Plan a maintenance, create it in statuspage for all Renku deployments managed by us. Coordinate with externally managed Renku deployments (Champak UniFR, Nicolas SV). | ||
* Merge terraform-renku PR. | ||
* The product and yat teams should review the PR, paying attention to the changelog | ||
* The product team updates the `CHANGELOG.rst` file when needed to make it more user friendly and potentially highlight relevant features or disrupting changes. | ||
* Once the PR is merged, a GitHub release and corresponding tag should be made. | ||
|
||
## Quick release | ||
## Rollout [YAT] | ||
|
||
A non-urgent release is requested to be made in between sprints by any of the teams. | ||
|
||
### Pre-requisites [Graph, UI, RP] | ||
|
||
* Component update should not incur in downtime, other than the restart of the updated component. | ||
* Announce half a day in advance. | ||
* Create a Pull Request in the `renku` repository with updates relevant -and adapted- to USERS and ADMINS in the `CHANGELOG.rst` file. | ||
* Ask the Product team for a review on the PR in Renku repository and tag the new release. | ||
* Create a Pull Request in the `terraform-renku` repository to update the version and make any needed configuration changes. | ||
|
||
### Process [YAT] | ||
|
||
* Plan a maintenance, create it in statuspage for all Renku deployments managed by us. Coordinate with externally managed Renku deployments (UniFR, SV). | ||
* Merge Pull Request in terraform-renku repository. | ||
* Before _any_ rollout is done, consider whether any of the upgrades will result in a longer-than-normal outage. If yes, create appropriate maintenance windows marking specific components as affected. Coordinate maintenance windows with external Renku deployments admins (UniFR, SV). | ||
* Roll out the release: one PR per deployment is automatically created in the `terraform-renku` repository to update the version. Make any needed configuration changes to the PR. Approve and merge the PR to deploy. Important: if needed, add the `scheduled maintenance` label to help avoiding it being merged too early. Limited should be rolled out before Renkulab, as a canary release (see below). | ||
* Limited should be rolled out ~1 week before the Renkulab rollout, to give a chance to find bugs early. E.g. Limited on Wednesday and Renkulab on Monday. | ||
* Make the tag in the `renku` repository, monitor the automatic process of chart publishing and deployment on staging. | ||
* Merge terraform-renku PR, monitor Flux upgrading Renku everywhere. | ||
* After the Limited and RenkuLab deployments are completed, notify the Product team that the deployments are live, so they can post the release Highlights. |