chore(docs): update release_process docs #6353
Conversation
kschelonka
force-pushed
the
mntor-5133-2
branch
from
845697d to
2347dc8
Compare
Vinnl
left a comment
Vinnl
left a comment
There was a problem hiding this comment.
Thanks Kat! Really great to have this knowledge shared more widely; I didn't really feel comfortable not knowing how our deployment process was set up anymore.
docs/release_process.md
Outdated
|
|
||
| - All production releases must follow the date tag naming scheme or else they will not be deployed. The regex for image deployments is in the [monitor tenant definition file](https://github.com/mozilla/global-platform-admin/blob/main/tenants/monitor.yaml). | ||
| - Example: `2024.09.01`; also can include additional numeric suffix preceded by a period, e.g. `2024.09.01.1` (for manually created deployments, typically hotfixes) | ||
| - All dev releases must use the short commit SHA as the tag or else they will not be deployed |
There was a problem hiding this comment.
Am I reading that YAML file right if I think that this is the case?
| - All dev releases must use the short commit SHA as the tag or else they will not be deployed | |
| - All dev releases must use `dev-` followed by the short commit SHA as the tag or else they will not be deployed, e.g. `dev-2347dc8` |
There was a problem hiding this comment.
I thought we were getting rid of the dev server?
There was a problem hiding this comment.
I don't think we should get rid of dev. It's a great place to test changes that aren't ready for main yet. Admittedly right now it's not very useful since we don't have a way to deploy to it without a main commit, but it could be
There was a problem hiding this comment.
Am I reading that YAML file right if I think that this is the case?
I will clarify the wording, but you should not manually make dev- prefix. The tag you choose to deploy must be a short commit sha, not one of the date tags. The deployment job adds the prefix.
There was a problem hiding this comment.
Ah, I get it now - thanks for the clarification!
| ### Daily pre-releases | ||
|
|
||
| Github pre-releases are generated daily via a (daily-pre-release)[daily-pre-release] GHA workflow. | ||
| Github pre-releases are generated daily via a [daily-pre-release](daily-pre-release) GHA workflow. |
There was a problem hiding this comment.
Are we still expected to manually cut a new release (separate from the automated daily pre-release), or should we be treating the generated pre-release as the final release candidate?
I’ve gotten into the habit of tagging a new release on top of the generated pre-release (e.g. 2025.17.02.1 a few hours later, usually to account for last-minute PRs or cases where staging lags behind the pre-release that may have been generated overnight. Just want to confirm whether that’s still the expected workflow.
There was a problem hiding this comment.
I didn't realize that was the expected workflow. I had assumed we were mostly promoting the pre-releases verified by QA unless there were later commits that needed to be released. @Vinnl thoughts here?
There was a problem hiding this comment.
Yeah my recent prod deploys were relatively uneventful, so I've been using the pre-releases without needing to merge last-minute PRs.
(That said, I'm not sure what the value of the daily prereleases is. It's not that much effort to create a new tag at release time, and I don't know what we'd ever use the intermediate releases for.)
There was a problem hiding this comment.
If we are moving Monitor more into a backend-only service, we can stop doing these pre-releases.
Pre-releases were started to make QAs workflows easier, by grouping a bunch of work together based on dates.
But if theoretically we won't need QAs in the loop anymore, the process can be a lot simpler, we can make the CICD go directly to prod via e2e and load tests
There was a problem hiding this comment.
@codemist re the original question, I think the easiest way (happy path) is to edit the generated daily pre-releases (if nothing needs to be changed) and just promote that one to "latest release"
And in the prod 1-click deploy workflow, we can just use that pre-release date tag as the tag to be deployed. I think I've done that a few times with no issue in the past
There was a problem hiding this comment.
Pre-releases were started to make QAs workflows easier, by grouping a bunch of work together based on dates.
But QA always tests whatever is currently on main (i.e. stage), not an arbitrary previous tag, so I think we can already disable them today. (Although probably not straight to prod yet.)
docs/release_process.md
Outdated
|
|
||
| New secrets are discovered automatically by ArgoCD every 5 minutes. You can also use annotations to force the discovery. However, new secrets will _not_ be automatically pulled into currently running pods. They will only be updated when the pods are restarted or the service redeployed (this includes new cron job instances). | ||
|
|
||
| To restart the pods for the monitor web application, navigate to [ArgoCD](https://webservices.argocd.global.mozgcp.net/applications?search=monitor) and select the project for the appropriate environment. Find the rollout resources `monitor-api-deployment` and `monitor-www`. On each node, click the hamburger menu and select "restart pods". ArgoCD will spin up new pods and terminate the existing ones. The new pods will have the updated environment variables. |
There was a problem hiding this comment.
In what scenario would restarting a pod be necessary? A little confused here as just before this "new secrets are discovered automatically by ArgoCD every 5 minutes", or is that a different thing?
There was a problem hiding this comment.
Always, the secrets are synced to the infrastructure but that doesn't mean the processes are reloaded to pick them up
mansaj
left a comment
mansaj
left a comment
There was a problem hiding this comment.
awesome, thanks for the update
References:
Jira: MNTOR-5133
Description
Update release_process docs post gcp-v2 migration. Add detail around how tags are deployed.