Release 11.3

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_3

  • 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_3

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

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

    • Title: Pick into 11.3
    • Description: Merge requests to cherry-pick into the `11-3-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-3-stable from CE master manually

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

  • In Omnibus create both 11-3-stable and 11-3-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

RC2

Issue: #421 (closed)

  • Update the blog post upgrade barometer section with the migration types for this release, including the time they took to complete.
  • Create an MR on CE master updating the "Installation from Source" guide, creating the "Update" guides
  • Create an MR on EE master creating the "CE to EE" guides
  • Ensure the above MRs are merged and marked ~"Pick into 11.3"

RC3

Issue: #425 (closed)

RC4

Issue: #427 (closed)

RC5

Issue: #431 (closed)

This is the first RC after the feature freeze.

RC6

Issue: #434 (closed)

RC7

Issue: #438 (closed)

RC8

Issue: #415 (closed)

RC9

Issue: #444 (closed)

RC10

Issue: #446 (closed)

RC11

Issue: #448 (closed)

RC12

Issue: #450 (closed)

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 Slack (update RC number):
/chatops run release_issue 11.3.0-rc7

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

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

  • 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.3"
    • Merge CE master into EE master
    • Integrate changes from master into 11-3-stable

  • In #development:

    @channel

`11-3-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-3-stable`.

Please ensure that merge requests have the correct milestone (`11.3` for this release)
and the `Pick into 11.3` 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 Slack (update RC number):
/chatops run release_issue 11.3.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:

    • Tag the 11.3.0 version using the release command:

      ```sh
# In Slack:
/chatops run tag 11.3.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.3.0-ee.0 -w

  • Before 12:00 UTC:

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

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

      ```sh
# In the takeoff project:
bin/takeoff-deploy -e gstg -v 11.3.0-ee.0
```
    Currently there is no Canary on GCP so canary deployment can be skipped.

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

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

      ```sh
# In the takeoff project:
bin/takeoff-deploy -e canary -v 11.3.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.3.0 to GitLab.com

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

  • At 14:30 UTC:

    • Publish the packages via ChatOps: 
      # In Slack:
/chatops run publish 11.3.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.3.0 version on version.gitlab.com
    • Ensure someone tweets about the 11.3.0 release in the #releases channel
Edited by Bob Van Landuyt