Skip to content
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

Merged
merged 9 commits into from
Jul 12, 2024

Conversation

fryorcraken
Copy link
Collaborator

@fryorcraken fryorcraken commented Jun 20, 2024

New detailed release process that involves more validation in Status app context.

Some decisions explanation (feel free to debate):

  • Release isn't finalised until validated with Status
    • 2024 is focus on Status, it seems less costly to block release until checked in Status context than doing patch releases.
    • Problems introduced in latest release blocked Status QA (nwaku blocked node), we must avoid this in the future.
  • Which means release process now takes 2 weeks:
    • 1st week testing release on Waku fleet
    • 2nd week testing release on Status fleet
  • Added task to create a summary of changes impact on Status users: needed to know what we check in the Status app beyond sanity check.

Also:

@fryorcraken fryorcraken requested a review from a team June 20, 2024 01:56
@fryorcraken fryorcraken changed the title New release process to include Status fleets docs: new release process to include Status fleets Jun 20, 2024
Copy link
Collaborator

@Ivansete-status Ivansete-status left a 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:

  1. create the release branch
  2. update the CHANGELOG.md accordingly in the release branch
  3. cherry-pick any interesting new commit from master to the release branch
  4. once release is validated and deployed, then merge the release branch into master, but without removing the release branch

.github/ISSUE_TEMPLATE/prepare_release.md Outdated Show resolved Hide resolved
.github/ISSUE_TEMPLATE/prepare_release.md Outdated Show resolved Hide resolved
.github/ISSUE_TEMPLATE/prepare_release.md Show resolved Hide resolved
Copy link
Contributor

@gabrielmer gabrielmer left a 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 😍

.github/ISSUE_TEMPLATE/prepare_release.md Show resolved Hide resolved
Comment on lines 53 to 57
- [ ] [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`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [ ] [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`)
Copy link
Contributor

@gabrielmer gabrielmer Jun 20, 2024

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

Copy link
Collaborator

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

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.

Comment on lines 55 to 58
- [ ] [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`)
Copy link
Collaborator Author

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator Author

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?

Copy link
Collaborator

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.)

Copy link
Collaborator Author

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.

@gabrielmer gabrielmer self-requested a review June 21, 2024 07:40
Copy link
Contributor

@gabrielmer gabrielmer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks so much!

Comment on lines 56 to 58
- [ ] Deploy final release to `waku.prod`
- [ ] Deploy final release to `status.staging`
- [ ] Deploy final release to `status.test` (soon to be `status.prod`)
Copy link
Collaborator

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.

Suggested change
- [ ] 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`)

Copy link
Collaborator Author

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?

Copy link
Collaborator

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

Comment on lines 55 to 58
- [ ] [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`)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fryorcraken
Copy link
Collaborator Author

Need to add running status-cli tests against nwaku release candidate.

@fryorcraken
Copy link
Collaborator Author

  • what do we do for mobile? - light client
  • need to be sure to log results on an issue

@fryorcraken
Copy link
Collaborator Author

  • Also ensure that deploy date does not conflict with ongoing Status/QA tests
  • contact request might not be needed

@fryorcraken
Copy link
Collaborator Author

  • Clarify who are the actors/owners

@fryorcraken
Copy link
Collaborator Author

At which point do we ask Vac/QA to run their test suite against the release candidate?

@Ivansete-status
Copy link
Collaborator

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 waku.test and shards.staging running for one week.

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 shards.staging.

@fryorcraken
Copy link
Collaborator Author

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 waku.test and shards.staging running for one week.

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 shards.staging.

Hi @Ivansete-status, I mean the Vac-QA team. if Vac-DST is also able to run test for mesh stability, that is good.
Ultimately, I'd like to see Vac-DST running performance difference between release to ensure non regression.

@fryorcraken fryorcraken force-pushed the prod-promotion-status branch 2 times, most recently from 53c568a to ddee9ad Compare July 2, 2024 06:57
- [ ] 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`
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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.

@fryorcraken
Copy link
Collaborator Author

@waku-org/nwaku-developers I think this is ready to merge. Let me know.

Copy link
Contributor

@NagyZoltanPeter NagyZoltanPeter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks massive!

Copy link
Collaborator

@Ivansete-status Ivansete-status left a 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.
Copy link
Collaborator

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 :)

Suggested change
- [ ] Submit a PR from the release branch to master. Important to commit the PR with "create a merge commit" option.

@fryorcraken fryorcraken merged commit 4264666 into master Jul 12, 2024
8 checks passed
@fryorcraken fryorcraken deleted the prod-promotion-status branch July 12, 2024 06:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants