Release 12.2

First steps

• Create a new slack channel #f_release_12_2
• Set the channel topic to RMs: https://about.gitlab.com/release-managers
• Invite all current release managers
• Inside the old release slack channel, notify about #f_release_12_2

  Hello :wave:
  We are starting 12.2 into #f_release_12_2
  Please archive this channel and join #f_release_12_2 if interested

• Determine latest day of the month where we'd create the stable branch: 19th August 2019______
  • This will be known as the freeze date

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, preferrably after all QA tasks are accounted and checked
• Monitor for any blockers to production and determine if canary should be disabled

Release Candidate

• Follow instructions in the release candidate issue on the aforementioned freeze date

Keep in mind that:

1. After the freeze date 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.

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):

  • Ensure tests are green on CE stable branch
  • Ensure tests are green on EE stable branch
  • Ensure tests are green on Omnibus CE stable branch
  • Ensure tests are green on Omnibus EE stable branch
  • Ensure master and stable branches are synced

• Before 10:00 UTC:

  • Tag 12.2.0:

    # In Slack:
    /chatops run release tag 12.2.0

  • Check progress of EE packages build and CE packages build

• Before 12:00 UTC:

  • Deploy 12.2.0 to the canary VMs on gitlab.com

    # In Slack:
    /chatops run deploy 12.2.0-ee.0 --production --canary

  • Confirm that there are no errors on canary
    • canary errors on sentry.gitlab.net
    • canary dashboard

• At 13:30 UTC:

  • Publish the packages via ChatOps:

    # In Slack:
    /chatops run publish 12.2.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 12.2.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 12.2.0 release. If they don't respond, ensure someone else tweets from the #releases channel