diff --git a/RELEASE.md b/RELEASE.md index 692303eb33..e552b2ef0f 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -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.