Skip to content

Commit

Permalink
chore: update release doc (#3430)
Browse files Browse the repository at this point in the history
  • Loading branch information
rokroskar authored Jan 23, 2024
1 parent e339ca4 commit 3d4534a
Showing 1 changed file with 41 additions and 77 deletions.
118 changes: 41 additions & 77 deletions RELEASE.md
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.

0 comments on commit 3d4534a

Please sign in to comment.