refresh release process #2109
refresh release process #2109
Conversation
🔍 Preview links for changed docs |
|
|
||
| ::::{step} [docs-builder PR] Approve and merge the config change | ||
|
|
||
| _This action must be performed by docs engineering._ |
There was a problem hiding this comment.
I don't think this must be done by docs engineering.
As long as the checks are passing, everyone can proceed with merging.
There was a problem hiding this comment.
assuming this means docs team - other areas of eng are blocked from this
https://elastic.slack.com/archives/C0JF80CJZ/p1760343688213179
There was a problem hiding this comment.
can anyone invoke the Synchronize version & config updates action, or should only docs eng do that?
There was a problem hiding this comment.
anyone can do it with Write access to the repo
There was a problem hiding this comment.
so for docs-builder https://github.com/orgs/elastic/teams/docs has write access
and for the docs-internal-workflows https://github.com/orgs/elastic/teams/docs-tech-leads have write access
|
|
||
| ::::{step} After feature freeze: merge the config change to staging | ||
|
|
||
| _This action must be performed by docs engineering._ |
There was a problem hiding this comment.
@elastic/docs-tech-leads are also able to merge the config.
The process I follow is:
- merge the config update PR
- deploy to staging (manually or wait for the next cron trigger)
- if everything is green and synthetics are not alerting, we can proceed with updating it in prod
There was a problem hiding this comment.
if everything is green and synthetics are not alerting, we can proceed with updating it in prod
where do we check this?
There was a problem hiding this comment.
if the deployment workflow to staging is green.
https://github.com/elastic/docs-internal-workflows/actions/workflows/assembler-build.staging.yml
There was a problem hiding this comment.
then I usually wait for 10-15 minutes..
if something goes wrong.. docs-engineers will get an alert
| ::::{step} Release a new version of docs-builder | ||
| ::::{step} Release day: merge the config change to prod and release to production | ||
|
|
||
| _This action must be performed by docs engineering. For most products, this change must be merged on release day._ |
There was a problem hiding this comment.
Here also, @elastic/docs-tech-leads are able to perform this.
Also, if everything went fine with staging. I'm pretty confident it will also just work for prod.
|
@reakaleek can you spot check my changes please? :) |
Update the tutorial we have for bumping a version in docs v3
After we have this centralized tutorial, we can cut down on steps in templates so we can reduce the # of surfaces that need to be updated when this process is enhanced (e.g. https://github.com/elastic/dev/pull/3321, https://github.com/elastic/dev/pull/3326, +++++)
Also fixed some stray references to including the base version in the legacy versions array (no longer needed as of #1865)
Does cache busting need to be reflected in this process?