mirror of
https://github.com/logos-messaging/logos-delivery.git
synced 2026-03-15 13:33:10 +00:00
Change release process (#3750)
* Simplify release process and leave the DST validation for deployment process * Rename prepare_full_release.md to prepare_release.md * Remove release-process.md as it duplicates info and causes confusion
This commit is contained in:
Ivan FB
GitHub
parent
1ace0154d3
commit
a77870782a
63
.github/ISSUE_TEMPLATE/prepare_beta_release.md
vendored
63
.github/ISSUE_TEMPLATE/prepare_beta_release.md
vendored
@ -1,63 +0,0 @@
|
||||
---
|
||||
name: Prepare Beta Release
|
||||
about: Execute tasks for the creation and publishing of a new beta release
|
||||
title: 'Prepare beta release 0.0.0'
|
||||
labels: beta-release
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
Add appropriate release number to title!
|
||||
|
||||
For detailed info on the release process refer to https://github.com/logos-messaging/logos-delivery/blob/master/docs/contributors/release-process.md
|
||||
-->
|
||||
|
||||
### Items to complete
|
||||
|
||||
All items below are to be completed by the owner of the given release.
|
||||
|
||||
- [ ] Create release branch with major and minor only ( e.g. release/v0.X ) if it doesn't exist.
|
||||
- [ ] Assign release candidate tag to the release branch HEAD (e.g. `v0.X.0-beta-rc.0`, `v0.X.0-beta-rc.1`, ... `v0.X.0-beta-rc.N`).
|
||||
- [ ] Generate and edit release notes in CHANGELOG.md.
|
||||
|
||||
- [ ] **Validation of release candidate**
|
||||
- [ ] **Automated testing**
|
||||
- [ ] Ensure all the unit tests (specifically logos-messaging-js tests) are green against the release candidate.
|
||||
- [ ] **Waku fleet testing**
|
||||
- [ ] Deploy the release candidate to `waku.test` through [deploy-waku-test job](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-test/) and wait for it to finish (Jenkins access required; ask the infra team if you don't have it).
|
||||
- After completion, disable fleet so that daily CI does not override your release candidate.
|
||||
- Verify at https://fleets.waku.org/ that the fleet is locked to the release candidate image.
|
||||
- Confirm the container image exists on [Harbor](https://harbor.status.im/harbor/projects/9/repositories/nwaku/artifacts-tab).
|
||||
- [ ] Search [Kibana logs](https://kibana.infra.status.im/app/discover) from the previous month (since the last release was deployed) for possible crashes or errors in `waku.test`.
|
||||
- Set time range to "Last 30 days" (or since last release).
|
||||
- Most relevant search query: `(fleet: "waku.test" AND message: "SIGSEGV")`, `(fleet: "waku.test" AND message: "exception")`, `(fleet: "waku.test" AND message: "error")`.
|
||||
- Document any crashes or errors found.
|
||||
- [ ] If `waku.test` validation is successful, deploy to `waku.sandbox` using the [deploy-waku-sandbox job](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox/).
|
||||
- [ ] Search [Kibana logs](https://kibana.infra.status.im/app/discover) for `waku.sandbox`: `(fleet: "waku.sandbox" AND message: "SIGSEGV")`, `(fleet: "waku.sandbox" AND message: "exception")`, `(fleet: "waku.sandbox" AND message: "error")`. most probably if there are no crashes or errors in `waku.test`, there will be no crashes or errors in `waku.sandbox`.
|
||||
- [ ] Enable the `waku.test` fleet again to resume auto-deployment of the latest `master` commit.
|
||||
|
||||
- [ ] **Proceed with release**
|
||||
|
||||
- [ ] Assign a final release tag (`v0.X.0-beta`) to the same commit that contains the validated release-candidate tag (e.g. `v0.X.0-beta-rc.N`) and submit a PR from the release branch to `master`.
|
||||
- [ ] Update [logos-delivery-compose](https://github.com/logos-messaging/logos-delivery-compose) and [logos-delivery-simulator](https://github.com/logos-messaging/waku-simulator) according to the new release.
|
||||
- [ ] Bump logos-delivery dependency in [logos-delivery-rust-bindings](https://github.com/logos-messaging/logos-delivery-rust-bindings) and make sure all examples and tests work.
|
||||
- [ ] Bump logos-delivery dependency in [logos-delivery-go-bindings](https://github.com/logos-messaging/logos-delivery-go-bindings) and make sure all tests work.
|
||||
- [ ] Create GitHub release (https://github.com/logos-messaging/logos-delivery/releases).
|
||||
- [ ] Submit a PR to merge the release branch back to `master`. Make sure you use the option "Merge pull request (Create a merge commit)" to perform the merge. Ping repo admin if this option is not available.
|
||||
|
||||
- [ ] **Promote release to fleets**
|
||||
- [ ] Ask the PM lead to announce the release.
|
||||
- [ ] Update infra config with any deprecated arguments or changed options.
|
||||
- [ ] Update waku.sandbox with [this deployment job](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox/).
|
||||
|
||||
### Links
|
||||
|
||||
- [Release process](https://github.com/logos-messaging/logos-delivery/blob/master/docs/contributors/release-process.md)
|
||||
- [Release notes](https://github.com/logos-messaging/logos-delivery/blob/master/CHANGELOG.md)
|
||||
- [Fleet ownership](https://www.notion.so/Fleet-Ownership-7532aad8896d46599abac3c274189741?pvs=4#d2d2f0fe4b3c429fbd860a1d64f89a64)
|
||||
- [Infra-nim-waku](https://github.com/status-im/infra-nim-waku)
|
||||
- [Jenkins](https://ci.infra.status.im/job/nim-waku/)
|
||||
- [Fleets](https://fleets.waku.org/)
|
||||
- [Harbor](https://harbor.status.im/harbor/projects/9/repositories/nwaku/artifacts-tab)
|
||||
- [Kibana](https://kibana.infra.status.im/app/)
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
name: Prepare Full Release
|
||||
name: Prepare Release
|
||||
about: Execute tasks for the creation and publishing of a new full release
|
||||
title: 'Prepare full release 0.0.0'
|
||||
title: 'Prepare release 0.0.0'
|
||||
labels: full-release
|
||||
assignees: ''
|
||||
|
||||
@ -26,6 +26,9 @@ All items below are to be completed by the owner of the given release.
|
||||
- [ ] **Automated testing**
|
||||
- [ ] Ensure all the unit tests (specifically logos-messaging-js tests) are green against the release candidate.
|
||||
|
||||
- [ ] **QA testing**
|
||||
- [ ] Ask QA to run their available tests against the release candidate.
|
||||
|
||||
- [ ] **Waku fleet testing**
|
||||
- [ ] Deploy the release candidate to `waku.test` fleet.
|
||||
- Start the [deployment job](https://ci.infra.status.im/job/nim-waku/) and wait for it to finish (Jenkins access required; ask the infra team if you don't have it).
|
||||
@ -36,40 +39,32 @@ All items below are to be completed by the owner of the given release.
|
||||
- Set time range to "Last 30 days" (or since last release).
|
||||
- Most relevant search query: `(fleet: "waku.test" AND message: "SIGSEGV")`, `(fleet: "waku.test" AND message: "exception")`, `(fleet: "waku.test" AND message: "error")`.
|
||||
- Document any crashes or errors found.
|
||||
- [ ] If `waku.test` validation is successful, deploy to `waku.sandbox` using the same [deployment job](https://ci.infra.status.im/job/nim-waku/).
|
||||
- [ ] Search [Kibana logs](https://kibana.infra.status.im/app/discover) for `waku.sandbox`: `(fleet: "waku.sandbox" AND message: "SIGSEGV")`, `(fleet: "waku.sandbox" AND message: "exception")`, `(fleet: "waku.sandbox" AND message: "error")`. most probably if there are no crashes or errors in `waku.test`, there will be no crashes or errors in `waku.sandbox`.
|
||||
- [ ] Ask QA to perform tests against `waku.test`, if any. Then, after that, review Kibana for possible issues or unexpected restart.
|
||||
- [ ] Enable the `waku.test` fleet again to resume auto-deployment of the latest `master` commit.
|
||||
|
||||
- [ ] **QA and DST testing**
|
||||
- [ ] Ask Vac-QA and Vac-DST to run their available tests against the release candidate; share all release candidates with both teams.
|
||||
- [ ] Vac-DST: An additional report is needed ([see this example](https://www.notion.so/DST-Reports-1228f96fb65c80729cd1d98a7496fe6f)). Inform DST team about what are the expectations for this rc. For example, if we expect higher or lower bandwidth consumption.
|
||||
|
||||
- [ ] **Status fleet testing**
|
||||
- [ ] Deploy release candidate to `status.staging`
|
||||
- [ ] **Status testing**
|
||||
- [ ] Get QA approval to deploy a new version in `status.staging`.
|
||||
- [ ] Deploy release candidate to `status.staging`.
|
||||
- [ ] Perform [sanity check](https://www.notion.so/How-to-test-Nwaku-on-Status-12c6e4b9bf06420ca868bd199129b425) and log results as comments in this issue.
|
||||
- [ ] Connect 2 instances to `status.staging` fleet, one in relay mode, the other one in light client.
|
||||
- 1:1 Chats with each other
|
||||
- Send and receive messages in a community
|
||||
- Close one instance, send messages with second instance, reopen first instance and confirm messages sent while offline are retrieved from store
|
||||
- [ ] Connect 2 instances to `status.staging` fleet, one in relay mode, the other one in light client mode.
|
||||
- 1:1 Chats with each other.
|
||||
- Send and receive messages in a community.
|
||||
- Close one instance, send messages with second instance, reopen first instance and confirm messages sent while offline are retrieved from store.
|
||||
- [ ] Perform checks based on _end user impact_
|
||||
- [ ] Inform other (Waku and Status) CCs to point their instances to `status.staging` for a few days. Ping Status colleagues on their Discord server or in the [Status community](https://status.app/c/G3kAAMSQtb05kog3aGbr3kiaxN4tF5xy4BAGEkkLwILk2z3GcoYlm5hSJXGn7J3laft-tnTwDWmYJ18dP_3bgX96dqr_8E3qKAvxDf3NrrCMUBp4R9EYkQez9XSM4486mXoC3mIln2zc-TNdvjdfL9eHVZ-mGgs=#zQ3shZeEJqTC1xhGUjxuS4rtHSrhJ8vUYp64v6qWkLpvdy9L9) (this is not a blocking point.)
|
||||
- [ ] Ask Status-QA to perform sanity checks (as described above) and checks based on _end user impact_; specify the version being tested
|
||||
- [ ] Ask Status-QA or infra to run the automated Status e2e tests against `status.staging`
|
||||
- [ ] Ask QA to perform sanity checks (as described above) and checks based on _end user impact_; specify the version being tested
|
||||
- [ ] Ask QA or infra to run the automated Status e2e tests against `status.staging`
|
||||
- [ ] Get other CCs' sign-off: they should comment on this PR, e.g., "Used the app for a week, no problem." If problems are reported, resolve them and create a new RC.
|
||||
- [ ] **Get Status-QA sign-off**, ensuring that the `status.test` update will not disturb ongoing activities.
|
||||
|
||||
- [ ] **Proceed with release**
|
||||
|
||||
- [ ] Assign a final release tag (`v0.X.0`) to the same commit that contains the validated release-candidate tag (e.g. `v0.X.0`).
|
||||
- [ ] Assign a final release tag (`v0.X.0`) to the same commit that contains the validated release-candidate tag (e.g. `git tag -as v0.X.0 -m "final release."`).
|
||||
- [ ] Update [logos-delivery-compose](https://github.com/logos-messaging/logos-delivery-compose) and [logos-delivery-simulator](https://github.com/logos-messaging/logos-delivery-simulator) according to the new release.
|
||||
- [ ] Bump logos-delivery dependency in [logos-delivery-rust-bindings](https://github.com/logos-messaging/logos-delivery-rust-bindings) and make sure all examples and tests work.
|
||||
- [ ] Bump logos-delivery dependency in [logos-delivery-go-bindings](https://github.com/logos-messaging/logos-delivery-go-bindings) and make sure all tests work.
|
||||
- [ ] Create GitHub release (https://github.com/logos-messaging/logos-delivery/releases).
|
||||
- [ ] Submit a PR to merge the release branch back to `master`. Make sure you use the option "Merge pull request (Create a merge commit)" to perform the merge. Ping repo admin if this option is not available.
|
||||
|
||||
- [ ] **Promote release to fleets**
|
||||
- [ ] Ask the PM lead to announce the release.
|
||||
- [ ] Update infra config with any deprecated arguments or changed options.
|
||||
- [ ] Create a deployment issue with the recently created release.
|
||||
|
||||
### Links
|
||||
|
||||
@ -1,164 +0,0 @@
|
||||
# Release Process
|
||||
|
||||
How to do releases.
|
||||
|
||||
For more context, see https://trunkbaseddevelopment.com/branch-for-release/
|
||||
|
||||
## How to do releases
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- All issues under the corresponding release [milestone](https://github.com/waku-org/nwaku/milestones) have been closed or, after consultation, deferred to the next release.
|
||||
- All submodules are up to date.
|
||||
> Updating submodules requires a PR (and very often several "fixes" to maintain compatibility with the changes in submodules). That PR process must be done and merged a couple of days before the release.
|
||||
|
||||
> In case the submodules update has a low effort and/or risk for the release, follow the ["Update submodules"](./git-submodules.md) instructions.
|
||||
|
||||
> If the effort or risk is too high, consider postponing the submodules upgrade for the subsequent release or delaying the current release until the submodules updates are included in the release candidate.
|
||||
|
||||
### Release types
|
||||
|
||||
- **Full release**: follow the entire [Release process](#release-process--step-by-step).
|
||||
|
||||
- **Beta release**: skip just `6c` and `6d` steps from [Release process](#release-process--step-by-step).
|
||||
|
||||
- Choose the appropriate release process based on the release type:
|
||||
- [Full Release](../../.github/ISSUE_TEMPLATE/prepare_full_release.md)
|
||||
- [Beta Release](../../.github/ISSUE_TEMPLATE/prepare_beta_release.md)
|
||||
|
||||
### Release process ( step by step )
|
||||
|
||||
1. Checkout a release branch from master
|
||||
|
||||
```
|
||||
git checkout -b release/v0.X.0
|
||||
```
|
||||
|
||||
2. Update `CHANGELOG.md` and ensure it is up to date. Use the helper Make target to get PR based release-notes/changelog update.
|
||||
|
||||
```
|
||||
make release-notes
|
||||
```
|
||||
|
||||
3. Create a release-candidate tag with the same name as release and `-rc.N` suffix a few days before the official release and push it
|
||||
|
||||
```
|
||||
git tag -as v0.X.0-rc.0 -m "Initial release."
|
||||
git push origin v0.X.0-rc.0
|
||||
```
|
||||
|
||||
This will trigger a [workflow](../../.github/workflows/pre-release.yml) which will build RC artifacts and create and publish a GitHub release
|
||||
|
||||
4. Open a PR from the release branch for others to review the included changes and the release-notes
|
||||
|
||||
5. In case additional changes are needed, create a new RC tag
|
||||
|
||||
Make sure the new tag is associated
|
||||
with CHANGELOG update.
|
||||
|
||||
```
|
||||
# Make changes, rebase and create new tag
|
||||
# Squash to one commit and make a nice commit message
|
||||
git rebase -i origin/master
|
||||
git tag -as v0.X.0-rc.1 -m "Initial release."
|
||||
git push origin v0.X.0-rc.1
|
||||
```
|
||||
|
||||
Similarly use v0.X.0-rc.2, v0.X.0-rc.3 etc. for additional RC tags.
|
||||
|
||||
6. **Validation of release candidate**
|
||||
|
||||
6a. **Automated testing**
|
||||
- Ensure all the unit tests (specifically js-waku tests) are green against the release candidate.
|
||||
|
||||
6b. **Waku fleet testing**
|
||||
- Start job on `waku.test` [Deployment job](https://ci.infra.status.im/job/nim-waku/), wait for completion of the job. If it fails, then debug it.
|
||||
- After completion, disable fleet so that daily ci not override your release candidate.
|
||||
- Verify at https://fleets.waku.org/ that the fleet is locked to the release candidate image.
|
||||
- Check if the image is created at [Harbor](https://harbor.status.im/harbor/projects/9/repositories/nwaku/artifacts-tab).
|
||||
- Search [Kibana logs](https://kibana.infra.status.im/app/discover) from the previous month (since the last release was deployed) for possible crashes or errors in `waku.test`.
|
||||
- Set time range to "Last 30 days" (or since last release).
|
||||
- Most relevant search query: `(fleet: "waku.test" AND message: "SIGSEGV")`, `(fleet: "waku.test" AND message: "exception")`, `(fleet: "waku.test" AND message: "error")`.
|
||||
- Document any crashes or errors found.
|
||||
- If `waku.test` validation is successful, deploy to `waku.sandbox` using the same [Deployment job](https://ci.infra.status.im/job/nim-waku/).
|
||||
- Search [Kibana logs](https://kibana.infra.status.im/app/discover) for `waku.sandbox`: `(fleet: "waku.sandbox" AND message: "SIGSEGV")`, `(fleet: "waku.sandbox" AND message: "exception")`, `(fleet: "waku.sandbox" AND message: "error")`. most probably if there are no crashes or errors in `waku.test`, there will be no crashes or errors in `waku.sandbox`.
|
||||
- Enable the `waku.test` fleet again to resume auto-deployment of the latest `master` commit.
|
||||
|
||||
6c. **QA and DST testing**
|
||||
- Ask Vac-QA and Vac-DST to run their available tests against the release candidate; share all release candidates with both teams.
|
||||
|
||||
> We need an additional report like [this](https://www.notion.so/DST-Reports-1228f96fb65c80729cd1d98a7496fe6f) specifically from the DST team. Inform DST team about what are the expectations for this rc. For example, if we expect higher or lower bandwidth consumption.
|
||||
|
||||
6d. **Status fleet testing**
|
||||
- Deploy release candidate to `status.staging`
|
||||
- Perform [sanity check](https://www.notion.so/How-to-test-Nwaku-on-Status-12c6e4b9bf06420ca868bd199129b425) and log results as comments in this issue.
|
||||
- Connect 2 instances to `status.staging` fleet, one in relay mode, the other one in light client.
|
||||
- 1:1 Chats with each other
|
||||
- Send and receive messages in a community
|
||||
- Close one instance, send messages with second instance, reopen first instance and confirm messages sent while offline are retrieved from store
|
||||
- Perform checks based on _end-user impact_.
|
||||
- Inform other (Waku and Status) CCs to point their instances to `status.staging` for a few days. Ping Status colleagues from their Discord server or [Status community](https://status.app) (not a blocking point).
|
||||
- Ask Status-QA to perform sanity checks (as described above) and checks based on _end user impact_; specify the version being tested.
|
||||
- Ask Status-QA or infra to run the automated Status e2e tests against `status.staging`.
|
||||
- Get other CCs' sign-off: they should comment on this PR, e.g., "Used the app for a week, no problem." If problems are reported, resolve them and create a new RC.
|
||||
- **Get Status-QA sign-off**, ensuring that the `status.test` update will not disturb ongoing activities.
|
||||
|
||||
7. Once the release-candidate has been validated, create a final release tag and push it.
|
||||
We also need to merge the release branch back into master as a final step.
|
||||
|
||||
```
|
||||
git checkout release/v0.X.0
|
||||
git tag -as v0.X.0 -m "final release." (use v0.X.0-beta as the tag if you are creating a beta release)
|
||||
git push origin v0.X.0
|
||||
git switch master
|
||||
git pull
|
||||
git merge release/v0.X.0
|
||||
```
|
||||
8. Update `waku-rust-bindings`, `waku-simulator` and `nwaku-compose` to use the new release.
|
||||
|
||||
9. Create a [GitHub release](https://github.com/waku-org/nwaku/releases) from the release tag.
|
||||
|
||||
* Add binaries produced by the ["Upload Release Asset"](https://github.com/waku-org/nwaku/actions/workflows/release-assets.yml) workflow. Where possible, test the binaries before uploading to the release.
|
||||
|
||||
### After the release
|
||||
|
||||
1. Announce the release on Twitter, Discord and other channels.
|
||||
2. Deploy the release image to [Dockerhub](https://hub.docker.com/r/wakuorg/nwaku) by triggering [the manual Jenkins deployment job](https://ci.infra.status.im/job/nim-waku/job/docker-manual/).
|
||||
> Ensure the following build parameters are set:
|
||||
> - `MAKE_TARGET`: `wakunode2`
|
||||
> - `IMAGE_TAG`: the release tag (e.g. `v0.38.0`)
|
||||
> - `IMAGE_NAME`: `wakuorg/nwaku`
|
||||
> - `NIMFLAGS`: `--colors:off -d:disableMarchNative -d:chronicles_colors:none -d:postgres`
|
||||
> - `GIT_REF` the release tag (e.g. `v0.38.0`)
|
||||
|
||||
### Performing a patch release
|
||||
|
||||
1. Cherry-pick the relevant commits from master to the release branch
|
||||
|
||||
```
|
||||
git cherry-pick <commit-hash>
|
||||
```
|
||||
|
||||
2. Create a release-candidate tag with the same name as release and `-rc.N` suffix
|
||||
|
||||
3. Update `CHANGELOG.md`. From the release branch, use the helper Make target after having cherry-picked the commits.
|
||||
|
||||
```
|
||||
make release-notes
|
||||
```
|
||||
Create a new branch and raise a PR with the changelog updates to master.
|
||||
|
||||
4. Once the release-candidate has been validated and changelog PR got merged, cherry-pick the changelog update from master to the release branch. Create a final release tag and push it.
|
||||
|
||||
5. Create a [GitHub release](https://github.com/waku-org/nwaku/releases) from the release tag and follow the same post-release process as usual.
|
||||
|
||||
### Links
|
||||
|
||||
- [Release process](https://github.com/waku-org/nwaku/blob/master/docs/contributors/release-process.md)
|
||||
- [Release notes](https://github.com/waku-org/nwaku/blob/master/CHANGELOG.md)
|
||||
- [Fleet ownership](https://www.notion.so/Fleet-Ownership-7532aad8896d46599abac3c274189741?pvs=4#d2d2f0fe4b3c429fbd860a1d64f89a64)
|
||||
- [Infra-nim-waku](https://github.com/status-im/infra-nim-waku)
|
||||
- [Jenkins](https://ci.infra.status.im/job/nim-waku/)
|
||||
- [Fleets](https://fleets.waku.org/)
|
||||
- [Harbor](https://harbor.status.im/harbor/projects/9/repositories/nwaku/artifacts-tab)
|
||||
- [Kibana](https://kibana.infra.status.im/app/)
|
||||
Loading…
x
Reference in New Issue
Block a user