|
| 1 | +--- |
| 2 | +name: Cut release and deploy |
| 3 | +about: Cut release and upgrade DevNet nodes |
| 4 | +title: Cut and deploy release 0.x.y |
| 5 | +labels: "" |
| 6 | +assignees: "" |
| 7 | +--- |
| 8 | + |
| 9 | +## Cut release |
| 10 | + |
| 11 | +Note: Some commands assume you are using the [fish](https://fishshell.com/) shell. |
| 12 | +If you are using other shells, you may need to adjust the commands accordingly. |
| 13 | +For example, `foo (bar)` in `fish` is equivalent to `foo $(bar)` in `bash`. |
| 14 | + |
| 15 | +The `VERSION` file specifies the release version to build, here referred to as `0.x.z`. |
| 16 | +The previous release is referred to as `0.x.y` in these instructions. |
| 17 | + |
| 18 | +Regular releases are started from `origin/main`, while bugfix / patch releases are started from a previous release line. |
| 19 | +For the rest of this checklist, this will be called the _ancestor branch_. |
| 20 | + |
| 21 | +Release versions can only be published from a _release line branch_. The _release line branch_ is `release-line-0.x.z` for release `0.x.z` in these instructions. |
| 22 | +A _release line branch_ is branched from the _ancestor branch_. |
| 23 | + |
| 24 | +- [ ] Choose the _ancestor branch_. This can be `origin/main` for all regular releases or `origin/release-line-0.x.y` for bugfix releases. |
| 25 | +- [ ] Wait for everything to be merged in the _ancestor branch_ that we want in `0.x.z`. |
| 26 | + - [ ] ... |
| 27 | +- [ ] Ensure all changes to the previous release branch `origin/release-line-0.x.y` are also included in both the _ancestor branch_ and `origin/main`. |
| 28 | + This should be the case but sometimes a change gets missed. |
| 29 | + - Use one of the following approaches to find changes applied to release line `0.x.y` after it was branched off its ancestor branch (which may be different from the ancestor branch of the new release). |
| 30 | + - Run `git diff (git merge-base origin/release-line-0.x.y ANCESTOR_BRANCH) origin/release-line-0.x.y` and compare it to the checked out source code of the release line you're upgrading to. |
| 31 | + - Run `git log (git merge-base origin/release-line-0.x.y ANCESTOR_BRANCH)..origin/release-line-0.x.y` and compare it to the log of the release line you're upgrading to. |
| 32 | + - Open https://github.com/DACH-NY/canton-network-node/compare/BRANCH_COMMIT...release-line-0.x.y to see the changes in the GitHub UI, where `BRANCH_COMMIT` is the commit that the release line was branched off from. |
| 33 | +- [ ] Merge a PR into the _ancestor branch_ with the following changes: |
| 34 | + - [ ] Update the release notes (`docs/src/release_notes.rst`): |
| 35 | + - Replace `Upcoming` by the target version |
| 36 | + - Fix any spelling mistakes and make sure the RST rendering is not broken |
| 37 | + - Check whether any important changes are missing, for example by briefly comparing the release notes with `git log 0.x.y..` (replace `0.x.y` with the prev version) |
| 38 | +- [ ] Create a release branch called `release-line-0.x.z` from the merged commit |
| 39 | + - Note: release branches are subject to branch protect rules. Once you push the branch, you need to open PRs to make further changes. |
| 40 | +- [ ] Merge a PR into the release branch (`origin/release-line-0.x.z`) with the following changes: |
| 41 | + - [ ] Create an empty commit with `[release]` in the commit message so it gets published as a non-snapshot version. You may have to edit the commit message when pressing the merge button in the GitHub UI. |
| 42 | +- [ ] Trigger a CircleCI pipeline from the DA-internal (on main) with `run-job: publish-release-artifacts` and `splice-git-ref: release-line-0.x.z` |
| 43 | +- [ ] If _ancestor branch_ is not `origin/main`, forward port all changes made to the _ancestor branch_ as part of this release to `origin/main` |
| 44 | +- [ ] Update the Open source repos, see https://github.com/DACH-NY/canton-network-node/blob/main/OPEN_SOURCE.md |
| 45 | + - [ ] Merge the auto-generated PR in https://github.com/digital-asset/decentralized-canton-sync |
| 46 | + - [ ] Merge the auto-generated PR in https://github.com/hyperledger-labs/splice |
| 47 | +- [ ] After merging the PR on the DA OSS repo, go to Releases in that repo |
| 48 | + (https://github.com/digital-asset/decentralized-canton-sync/releases), find the draft |
| 49 | + release for the release you just created and publish it (click the edit pencil icon). This should be done after merging the PR because it will |
| 50 | + also automatically bundle the sources from the release-line branch. |
| 51 | +- [ ] Merge a PR into the _ancestor branch_ with the following changes: |
| 52 | + - Update `VERSION` and `LATEST_RELEASE`. `VERSION` should be the next planned release (typically bumping the minor version), and `LATEST_RELEASE` should be the version of the newly created release line. |
| 53 | +- [ ] Communicate to partners that a new version is available |
| 54 | + |
| 55 | +## Upgrade our own nodes on DevNet |
| 56 | + |
| 57 | +- [ ] If significant time has passed since cutting the release, ensure that there are no changes that need to be backported to the release branch. |
| 58 | + In particular, check for changes to the `cluster/configs` and `cluster/configs-private` submodules. |
| 59 | +- [ ] Merge a PR into the release branch (`origin/release-line-0.x.z`) with the following changes: |
| 60 | + - [ ] Update the cluster `config.yaml` file by setting the new reference under `synchronizerMigration.active.releaseReference` and update the `synchronizerMigration.active.version` to version `0.x.y`. |
| 61 | + - [ ] Update `cluster/deployment/devnet/.envrc.vars`, bumping the release version. |
| 62 | + - Currently, the affected env vars are `OVERRIDE_VERSION`, `CHARTS_VERSION`, and `MULTI_VALIDATOR_IMAGE_VERSION`. |
| 63 | + - [ ] Before merging, open the `preview_pulumi_changes` CircleCi workflow and approve the jobs to generate `deployment` and `devnet` previews. |
| 64 | + Review the changes together with someone else, paying particular attention to deleted or newly created resources. |
| 65 | +- [ ] Warn our partners on [#supervalidator-operations](https://daholdings.slack.com/archives/C085C3ESYCT): "We'll be upgrading the DA-2 and DA-Eng nodes on DevNet to test a new version. Some turbulence might be expected." |
| 66 | +- [ ] Forward-port the changes to `config.yaml` and `cluster/deployment/devnet/.envrc.vars` to `main`. The `deployment` stack, which watches `main`, should pick that up |
| 67 | +and upgrade the other pulumi stacks. |
| 68 | +- [ ] Wait for [the operator](https://github.com/DACH-NY/canton-network-node/tree/main/cluster#the-operator) to apply your changes |
| 69 | + - A good check is `kubectl get stack -n operator -o json | jq '.items | .[] | {name: .metadata.name, status: .status}'` should show all stacks as successful and on the right commit. |
| 70 | + Remember to check that the `lastSuccessfulCommit` field points to the release line that you expect. |
| 71 | +- [ ] Confirm that we didn't break anything; for example: |
| 72 | + - [ ] The [SV Status Report Dashboard](https://grafana.dev.global.canton.network.digitalasset.com/d/caffa6f7-c421-4579-a839-b026d3b76826/sv-status-reports?orgId=1) looks green |
| 73 | + - [ ] There are no (unexpected) open alerts |
| 74 | + - [ ] The docs are reachable at both https://dev.network.canton.global/ and https://dev.global.canton.network.digitalasset.com/ |
| 75 | + |
| 76 | +## Upgrade our own nodes on TestNet and MainNet |
| 77 | + |
| 78 | +- [ ] One week after DevNet: TestNet |
| 79 | +- [ ] One week after TestNet: MainNet |
| 80 | + |
| 81 | +## Follow up |
| 82 | + |
| 83 | +- [ ] If you cut a release, remind the next person in the [rotation](https://docs.google.com/document/d/1f0nVeRnnxKQxwPi5nI2TiMq6qtHPwgiOjtUPUVJMKIk/edit?tab=t.0) that is up for cutting a release next week. |
| 84 | +- [ ] Persist any lessons learned and fix (documentation) bugs hit |
0 commit comments