Release 13.1
First steps
-
Join the slack channel #f_upcoming_release
-
Change the channel topic with /topic Issue: <link_to_this_issue>
-
Invite all current release managers -
Modify the dates below to accurately reflect the plan of action
Monitor
- Monitor QA issues for each deploy to
gstg
- Ensure any deploys that do not make it to canary are investigated
- Try to push any successful deploy to canary into production after some time has passed, preferably after all QA tasks are accounted and checked
- Monitor for any blockers to production and determine if canary should be disabled
11th
-
@skarbek to run /chatops run auto_deploy pause
at the end of his working day to prevent deployments on the 12th
13th
-
@nolith to run /chatops run auto_deploy unpause
, the change lock window will be in place to protect production, be we can create Sunday's auto-deploy branch
15th
-
Find the latest sha
that made it into production successfully:878770e1800c13248d55a3fcc60891c0c25c6963
-
Notify Engineering Managers that this is the sha
that is guaranteed to be released on the 22nd, in#releases
::mega: This is the latest commit running on GitLab.com and this is guaranteed to be released on the 22nd. https://gitlab.com/gitlab-org/gitlab/commits/878770e1800c13248d55a3fcc60891c0c25c6963 Another auto-deploy branch for the release will be created on the 16th. The inclusion of the auto-deploy branch created on the 16th in the release is subject to the usual caveats (CI green, successfully made it to GitLab.com by 20th)
-
Link the above message to additional channels: #development
,#backend
, and#frontend
16th 17th
-
Ensure today auto-deploy build makes it through into production -
Grab the 11b93a42e76dc88700837631511e031e730fe9dd
from this new auto-deploy branch and notify Engineering Managers that this is the candidatesha
for the release, in#releases
::mega: This is the _candidate_ commit to be released on the 22nd. https://gitlab.com/gitlab-org/gitlab/-/commit/11b93a42e76dc88700837631511e031e730fe9dd
-
Link the above message to additional channels: #development
,#backend
, and#frontend
18th
-
Determine what the last green auto deploy branch is and add it here: 13-1-auto-deploy-20200617
-
Create the stable branches using chatops by running the following in Slack: /chatops run release stable_branch 13.1.0
-
Verify that the CE stable branch contains the right commits - There should be at least two commits: the last commit from the previous stable branch (usually a version update), and the sync commit created by the merge train.
- The sync commit will have the message "Add latest changes from gitlab-org/gitlab@13-1-stable-ee"
-
Create a RC version to ensure that the final version builds correctly # In Slack: /chatops run release tag 13.1.0-rc42
-
Notify Engineering Managers that final candidate has been created in #releases
::mega: Barring any show-stopping issues, this is the final commit to be released on the 22nd. https://gitlab.com/gitlab-org/gitlab/-/commits/13-1-stable-ee
19th
-
At 18:00 UTC, confirm that final RC version has passed automated QA tests, and is functional -
Ensure tests are green on CE stable branch -
Ensure tests are green on EE stable branch -
Ensure tests are green on Omnibus -
Ensure master and stable branches are synced: /chatops run mirror status
-
-
After 18:00 UTC: -
Tag 13.1.0
:# In Slack: /chatops run release tag 13.1.0
-
Check progress of EE packages build and CE packages build
-
-
If 13.1.0
has not been deployed to the preprod environment already, deploy it manually with the following ChatOps command:sh # In Slack: /chatops run deploy 13.1.0-ee.0 --pre
Past this point, no new code can be added to the release that was not included in the final RC.
22nd: release day
Final release is tagged, so any changes will have to initiate a patch release.
-
At 13:00 UTC, post an update about the package building status in #f_upcoming_release
- At 13:30 UTC:
-
⚠ Make sure that neither packages nor the blog post get published earlier than 13:30UTC without approval by the messaging lead of the release post. Mind that you don't need their approval if you're on time⚠ -
Publish the packages via ChatOps: # In Slack: /chatops run publish 13.1.0
- If anything goes wrong and the release is delayed, ping the release post manager on Slack to make them aware of the issue. Cross-post the slack message to the #marketing channel to notify them too
-
- At 14:10 UTC:
-
Verify that packages appear on packages.gitlab.com
: EE / CE -
Verify that Docker images appear on hub.docker.com
: EE / CE -
Create the 13.1.0
version on version.gitlab.com -
Post an update about the status in #f_upcoming_release
-
Once all packages are available publicly and GitLab.com is up and running on the release version, ping the release post manager on Slack (#release-post channel) to give them a go to merge the release post at ~14:20 UTC, so that it will be live at 15:00 UTC
-
-
Open MR to Bump VERSION file to the next version to be released
Edited by John Skarbek