Release 11.2

First steps

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

  • Assign this issue to all the release managers and trainees

  • Create a new slack channel #f_release_11_2

  • Set the channel topic to RMs: https://about.gitlab.com/release-managers

  • Invite all current release managers

  • Inside the channel invite trainees to start their onboarding

    Welcome @TRAINEE_1 and @TRAINEE_2 :wave:
If you haven't done it already, please start your onboarding issue
https://gitlab.com/gitlab-org/release/docs/blob/master/quickstart/release-manager.md
Let us know if you have any questions!

  • Inside the old release slack channel, notify about #f_release_11_2

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

  • Create the ~"Pick into 11.2" group label if it doesn't exist: https://gitlab.com/groups/gitlab-org/labels/new

    • Title: Pick into 11.2
    • Description: Merge requests to cherry-pick into the `11-2-stable` branch.
    • Color: #00c8ca

  • Make sure the latest CE to EE on master branches is merged (it will reduce conflicts in the future). Ask in #ce-to-ee when in doubt.

  • Create branch 11-2-stable from CE master manually

  • Create branch 11-2-stable-ee from EE master manually

  • In Omnibus create both 11-2-stable and 11-2-stable-ee from master manually

  • Merge GitLab CE into EE on stable branches following the Merging a CE stable branch into its EE counterpart guide

  • Sync stable branches for CE, EE, and Omnibus to dev

  • Sync master branches to dev, as the CHANGELOG will be automatically updated on master during tagging

  • If needed, sync tags for dependencies (gitlab-shell, gitlab-workhorse, gitlab-pages, gitaly) to dev (when applicable. Builds should fail if this is needed.)

RC1

Subsequent RCs

  • Update the blog post upgrade barometer section with the migration types for this release, including the time they took to complete.

  • Create additional release candidates as needed:

    # In the release-tools project (update RC number):
/chatops run release issue 11.2.0-rc8

  • Link any subsequent RCs issues as a related issue in this issue

RC2

#383 (closed)

RC3

#385 (closed)

RC4

#386 (closed)

RC5

#390 (closed)

RC6

#393 (closed)

RC7

#395 (closed)

RC8

#397 (closed)

RC9

#399 (closed)

RC10 (Final RC)

#401 (closed)

Keep in mind that:

  1. After the feature freeze only regression and security 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

  • Follow the Feature freeze RC guide:

    • Create an MR on CE master updating the .gitignore, .gitlab-ci.yml, and Dockerfile templates
    • Create an MR on CE master updating the dependencies license list
    • Ensure the above MRs are merged and marked ~"Pick into 11.2"
    • Merge CE master into EE master
    • Integrate changes from master into 11-2-stable

  • In #development:

    @channel

`11-2-stable` branch has been created. Everything merged into `master`
after this point will go into next month's release. Only regression and security fixes
will be cherry-picked into `11-2-stable`.

Please ensure that merge requests have the correct milestone (`11.2` for this release)
and the `Pick into 11.2` label.

From now on, please follow the "After the 7th" process:
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/PROCESS.md#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 the release-tools project (update RC number):
bundle exec rake "patch_issue[11.2.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 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:

    • Tag the 11.2.0 version using the release command:

      ```sh
# In Slack
/chatops run tag 11.2.0
```

    • Check progress of EE packages build and CE packages build

    • Warm up the packages on takeoff by running: sh # In the takeoff project: bin/takeoff-deploy -v 11.2.0-ee.0 -w

  • Before 12:00 UTC:

    • Notify #production channel about staging deploy. No need to require confirmation.

    • On video call, deploy 11.2.0 to staging.gitlab.com

      ```sh
# In the takeoff project:
bin/takeoff-deploy -e staging -v 11.2.0-ee.0
```

    • Notify #production channel about canary deploy. No need to require confirmation.

    • On video call, deploy 11.2.0 to canary.gitlab.com

      ```sh
# In the takeoff project:
bin/takeoff-deploy -e canary -v 11.2.0-ee.0
```

    • Get confirmation from a production team member to deploy production. Use !oncall prod if needed to find who's on call. If someone besides the oncall confirms, @mention the oncall so they are aware.

    • On video call, deploy 11.2.0 to GitLab.com

      ```sh
# In the takeoff project:
bin/takeoff-deploy -e production -v 11.2.0-ee.0
```

  • At 14:30 UTC:

    • Publish the packages via ChatOps: 
      # In Slack
/chatops run publish 11.2.0
    • Make sure that neither packages nor the blog post get published early without approval by the marketing team

  • At 15:00 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.2.0 version on version.gitlab.com
    • Ensure someone tweets about the 11.2.0 release in the #releases channel
Edited by Julius Kvedaras