Skip to content

Release 13.10

First steps

  • Change #f_upcoming_release topic with /topic 13.10.0: <link_to_this_issue>
  • Modify the dates below to accurately reflect the plan of action

25th Feb (End of day)

  • Ensure that auto-deploys are stopped ahead of Friends & Family day
/chatops run auto_deploy pause

1st Mar

  • Ensure that auto-deploy continues
/chatops run auto_deploy unpause

Up until the 12th

  • Ensure any deploys that do not make it to canary are investigated. Disable canary if necessary.
  • Push any successful deploy to canary into production after some time has passed (preferably 1h).
  • Should any deployment blockers prevent automatic promotions to production, this requires approval by the SRE On-Call.
    1. Ask for permission to promote the release in #production - provide the necessary context to the Engineer
    2. If permission is granted, utilize the following command to initiate an overridden promotion: 
      /chatops run deploy <VERSION> --production --ignore-production-checks 'deployment approved by on call SRE'
    3. This will post a comment into this issue and begin the deployment
    4. Ask the SRE On-Call to respond to the comment with their approval for auditing purposes

12th

If this date is on a weekend, do this work on the next working day

  • Find the latest sha that made it into production successfully: sha
  • Notify Engineering Managers that this is the sha that is guaranteed to be released on the 22nd, in #releases: 
    /chatops run notify ":mega: This is the most recent commit running on GitLab.com and this is guaranteed to be released on the 22nd.
https://gitlab.com/gitlab-org/security/gitlab/commits/<SHA>
Please see the following documentation on what this means:
  * `https://about.gitlab.com/handbook/engineering/releases/#how-can-i-determine-if-my-merge-request-will-make-it-into-the-monthly-release`
  * `https://about.gitlab.com/handbook/engineering/releases/#when-do-i-need-to-have-my-mr-merged-in-order-for-it-to-be-included-into-the-monthly-release`
The release preparation is starting earlier this month due to Family & Friends day and support for JiHu"
  • Link the above message to additional channels: #development, #quality, #backend, and #frontend

15th

  • Log latest auto-deploy branch: 13-10-auto-deploy-2021031218
  • Ensure this build makes it through into production
  • Grab the sha from this new auto-deploy branch and notify Engineering Managers that this is the candidate sha for the release, in #releases: 
    /chatops run notify ":mega: This is the _candidate_ commit to be released on the 22nd.
https://gitlab.com/gitlab-org/security/gitlab/commits/6dcc1acd5fba09d9b8f5e19f526e2af9892fac8e.
Please see the following documentation on what this means:
  * `https://about.gitlab.com/handbook/engineering/releases/#how-can-i-determine-if-my-merge-request-will-make-it-into-the-monthly-release`
  * `https://about.gitlab.com/handbook/engineering/releases/#when-do-i-need-to-have-my-mr-merged-in-order-for-it-to-be-included-into-the-monthly-release`"

16th

If this date is on the weekend, do this work on the last Friday before the 20th.

This will use the latest commit deployed to production for the various components that we release. If a different commit is necessary for a component, such as GitLab, you should run the following instead:

/chatops run release tag 13.10.0-rc42 --gitlab-sha=XXX

This will then use XXX as the SHA to create the GitLab stable branches.

NOTE: this SHA is only used if the stable branch has yet to be created. If it already exists, the branch is left as-is.

  • 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-10-stable-ee"

  • 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/security/gitlab/-/commits/13-10-stable-ee

  • Link the above message to additional channels: #development, #quality, #backend, and #frontend

  • Verify that the RC has been deployed to the pre environment

17th

Complete these tasks near the end of AMER shift to allow time for tasks in https://gitlab.com/gitlab-jh/gitlab-jh-enablement/-/issues/98 to be completed

  • Confirm that final RC version has passed automated tests
    • Ensure tests are green on CE stable branch
    • Ensure tests are green on EE stable branch
    • Ensure tests are green on Omnibus
    • Ensure default and stable branches are synced: /chatops run mirror status
  • Tag 13.10.0: 
    # In Slack:
/chatops run release tag 13.10.0

18th

Instructions for manual deploy 
    ```sh
    # In Slack:
    /chatops run deploy 13.10.0-ee.0 --release
    ```
  • Validate 13.10.0 has been passed automated QA

Past this point, no new code can be added to the release that was not included in the final RC.

  • Ensure that auto-deploys are stopped ahead of Friends & Family day
/chatops run auto_deploy pause

22nd: release day

  • Ensure that auto-deploy continues
/chatops run auto_deploy unpause

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 
    :mega: Packages for 13.10.0 are built and will be published at 13:30UTC
  • 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.10.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 EE packages appear on packages.gitlab.com: EE (should contain 14 packages)
    • Verify that CE packages appear on packages.gitlab.com: CE (should contain 13 packages)
    • Verify that Docker images appear on hub.docker.com: EE / CE
    • Create the 13.10.0 version on version.gitlab.com
    • Post an update about the status in #f_upcoming_release 
    :mega: 13.10.0 is published and publicly available
    • 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
Edited by Yorick Peterse