-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: new release process to include Status fleets #2825
Conversation
19a5b79
to
9e1d57c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for that ❤️ ! I just added a few comments that I hope you find interesting.
In general, I like the new approach and the details.
IMO, only the release branch should receive cherry-picks from master if, during the release period, we consider an important commit that should be delivered and was merged after the creation of the release branch.
With that, I suggest the following lifetime for any release branch:
- create the release branch
- update the CHANGELOG.md accordingly in the release branch
- cherry-pick any interesting new commit from master to the release branch
- once release is validated and deployed, then merge the release branch into master, but without removing the release branch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much! It looks reaaally good 😍
- [ ] [deploy release to `waku.sandbox` fleet](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox) | ||
- [ ] announce the release | ||
|
||
- [ ] **Promote release to fleets**. | ||
- [ ] Deploy final release to `waku.prod` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- [ ] [deploy release to `waku.sandbox` fleet](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox) | |
- [ ] announce the release | |
- [ ] **Promote release to fleets**. | |
- [ ] Deploy final release to `waku.prod` | |
- [ ] announce the release | |
- [ ] **Promote release to fleets**. | |
- [ ] Deploy final release to `waku.sandbox` |
I think it should be like this instead, as waku.sandbox
is our "prod" fleet
|
||
- [ ] **On Waku fleets** | ||
- [ ] Lock `waku.test` fleet to release candidate version | ||
- [ ] Continuously stress `waku.test` fleet for a week (e.g. from `waku.sandbox`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think here it should be waku-dev
machine instead of waku.sandbox
We sometimes called the waku-dev
machine waku-sandbox
, so it might generate confusions. But IMO better to stick to the waku-dev
naming
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think here it should be
waku-dev
machine instead ofwaku.sandbox
We sometimes called the
waku-dev
machinewaku-sandbox
, so it might generate confusions. But IMO better to stick to thewaku-dev
naming
oh yes good point! I agree that the "sandbox" term is confusing (I will stop using it as well to refer to that machine ;P)
We can mention wakudev
or more specifically: metal-01.he-eu-hel1.wakudev.misc
.
9e1d57c
to
3580432
Compare
- [ ] [Deploy final release to `waku.sandbox` fleet](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox) | ||
- [ ] Deploy final release to `waku.prod` | ||
- [ ] Deploy final release to `status.staging` | ||
- [ ] Deploy final release to `status.test` (soon to be `status.prod`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add CI links for all these steps?
Or do the last steps means pinging infra?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good point!
Links:
waku.test
- https://ci.infra.status.im/job/nim-waku/job/deploy-waku-test/waku.sandbox
- https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox/shards.staging
- https://ci.infra.status.im/job/nim-waku/job/deploy-shards-staging/shards.test
- https://ci.infra.status.im/job/nim-waku/job/deploy-shards-test/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
won't nwaku master get deployed automatically to waku.test
? isn't it how ti works?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
won't nwaku master get deployed automatically to
waku.test
? isn't it how ti works?
Yes, you are absolutely right. Nevertheless, during the testing time, we disable the automatic deployments and leave the release candidate version running for some days (ideally one week.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you are absolutely right. Nevertheless, during the testing time, we disable the automatic deployments and leave the release candidate version running for some days (ideally one week.)
Yes, we have an entry unlock waku.test
already, so I assume the deployment will resume. Let me know if it's not clear enough in the new tempalte.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much!
- [ ] Deploy final release to `waku.prod` | ||
- [ ] Deploy final release to `status.staging` | ||
- [ ] Deploy final release to `status.test` (soon to be `status.prod`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have waku.prod
.
- [ ] Deploy final release to `waku.prod` | |
- [ ] Deploy final release to `status.staging` | |
- [ ] Deploy final release to `status.test` (soon to be `status.prod`) | |
- [ ] Deploy final release to `shards.staging` | |
- [ ] Deploy final release to `shards.test` (soon to be `status.prod`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't? What's TWN then? where do you deploy final Waku releases for TWN?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't? What's TWN then? where do you deploy final Waku releases for TWN?
Yes, TWN is deployed in waku.sandbox
.
Ah btw, I think we are missing to add a point where we update the version pointed by nwaku-compose
- [ ] [Deploy final release to `waku.sandbox` fleet](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox) | ||
- [ ] Deploy final release to `waku.prod` | ||
- [ ] Deploy final release to `status.staging` | ||
- [ ] Deploy final release to `status.test` (soon to be `status.prod`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good point!
Links:
waku.test
- https://ci.infra.status.im/job/nim-waku/job/deploy-waku-test/waku.sandbox
- https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox/shards.staging
- https://ci.infra.status.im/job/nim-waku/job/deploy-shards-staging/shards.test
- https://ci.infra.status.im/job/nim-waku/job/deploy-shards-test/
Need to add running status-cli tests against nwaku release candidate. |
3580432
to
6c7f994
Compare
|
|
|
At which point do we ask Vac/QA to run their test suite against the release candidate? |
I think this is something that we can run right after we create the release candidate, and before we have On the other hand, we need to properly define what we understand by "running VAC/QA test suite against a RC". Wrt VAC I first of all envision the process in which @AlbertoSoutullo helps us check that the mesh stability is reached reasonably fast. And re QA I'm envisioning running a Jenkins job. I think is that. In that case, I think that's something we can do ourselves manually if the Jenkins job just runs against the |
Hi @Ivansete-status, I mean the Vac-QA team. if Vac-DST is also able to run test for mesh stability, that is good. |
53c568a
to
ddee9ad
Compare
- [ ] Perform checks based _end user impact_ | ||
- [ ] Ask other (Waku and Status) CCs to point their instance to `status.staging` for a week and use the app as usual. | ||
- [ ] Ask Status-QA to perform sanity checks (as described above) + checks based on _end user impact_ | ||
- [ ] Ask Status-QA or infra to run the automated Status e2e tests against `status.staging` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We believe this is the test suite: https://ci.infra.status.im/job/status-desktop/job/e2e/job/manual/
unclear how to run it against a specific fleet (shards.staging
).
|
||
- [ ] Automated testing | ||
- [ ] Ensures js-waku tests are green against release candidate | ||
- [ ] Ask Vac-QA and Vac-DST to perform available tests against release candidate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- [ ] Submit a PR from the release branch to master. Important to commit the PR with "create a merge commit" option. | ||
|
||
- [ ] **Promote release to fleets**. | ||
- [ ] Update infra config with any deprecated arguments or changed options |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this to avoid bad surprises.
@waku-org/nwaku-developers I think this is ready to merge. Let me know. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks massive!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for it! 💯
I just added a minor comment but this is a great reference.
Testing in waku.test
and status.staging
could be made concurrently.
- [ ] Create GitHub release | ||
- [ ] Deploy the release to DockerHub | ||
- [ ] Announce the release | ||
- [ ] Submit a PR from the release branch to master. Important to commit the PR with "create a merge commit" option. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That line is mentioned as a post-release step :)
- [ ] Submit a PR from the release branch to master. Important to commit the PR with "create a merge commit" option. |
9198ce1
to
f70ca06
Compare
New detailed release process that involves more validation in Status app context.
Some decisions explanation (feel free to debate):
Also: