Skip to content
Snippets Groups Projects

Release 11.10

    • Closed Issue created by GitLab Release Tools Bot @gitlab-release-tools-bot

    First steps

    Stable branch should be created after the 7th. The 7th is the last date to reliably get things in.

    • Sync stable branches to dev
    • Sync master branches to dev
    • If needed, sync tags for dependencies (gitlab-shell, gitlab-workhorse, gitlab-pages, gitaly) to dev (when applicable. Builds should fail if this is needed.)
    • Repeat the process of syncing stable branches until the Feature Freeze date

    Release candidates

    • Create additional release candidates as needed:

      # In Slack (update RC number):
/chatops run release prepare 11.10.0-rc2

    Keep in mind that:

    1. After the feature freeze only regression, security, and documentation fixes should be cherry-picked into stable branches.
    2. The final RC should point to the same commit as the final release.

    On the first working day after the 7th

    Final RC

    The final RC should be created on the 21st of the month.

    Before 13:00 UTC

    Including changes at this stage requires signoff from the VP of Engineering.

    • Create a task list for the final RC:

      # In Slack (update RC number):
/chatops run release prepare 11.10.0-rc22

    At 15:00 UTC

    If the final RC isn't tagged and deployed by this time, notify the Distribution Lead.

    At 20:00 UTC

    If the final RC still isn't tagged and deployed by this time, notify the VP of Engineering.

    22nd: release day

    No new code can be added to the release that was not included in the final RC.

    • At 08:00 UTC, final release is ready for tagging (Including changes at this stage requires signoff from the VP of Engineering):

    • Before 10:00 UTC:

    • Before 12:00 UTC:

      • Deploy 11.10.0 to the canary VMs on gitlab.com 
        # In Slack:
/chatops run deploy 11.10.0-ee.0 --production --canary
      • Confirm that there are no errors on canary
      • Get confirmation from a production team member to deploy production. Use /chatops run oncall production if needed to find who's on call. If someone besides the oncall confirms, @mention the oncall so they are aware.
      • Confirm there are no critical alerts on gitlab.com on the alerting dashboard
      • Deploy 11.10.0 to GitLab.com 
        # In Slack:
/chatops run deploy 11.10.0-ee.0 --production

    • At 13:30 UTC:

      • Publish the packages via ChatOps: 
        # In Slack:
/chatops run publish 11.10.0
      • Make sure that neither packages nor the blog post get published earlier than planned without approval by the messaging lead of the release post. Mind that you don't need their approval if you're on time
      • 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 11.10.0 version on version.gitlab.com
      • 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
      • Make sure the release post manager will tweet about the 11.10.0 release. If they don't respond, ensure someone else tweets from the #releases channel
    6 of 31 checklist items completed · Edited by Marin Jankovski

    Designs

      Child items ...

      2. Activity

      Please register or sign in to reply