Skip to content

Release 11.1

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 manager and trainees

  • Create a new slack channel #f_release_11_1

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

  • invite all current and previous 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!

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

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

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

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

  • Follow the Creating RC1 guide:

    • 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

    • 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.1"

    • Create a task list for RC1:

      # In the release-tools project:
bundle exec rake "patch_issue[11.1.0-rc1]"

    • Link the RC1 issue as a related issue in this issue

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):
bundle exec rake "patch_issue[11.1.0-rc2]"

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

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 7th

  • In #development:

    @channel

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

Please ensure that merge requests have the correct milestone (`11.1` for this release)
and the `Pick into 11.1` 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.1.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.1.0 version using the tag command:

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

  • Before 12:00 UTC:

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

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

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

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

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

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

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

  • At 14:30 UTC:

    • Publish the packages via ChatOps: /chatops run publish 11.1.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.1.0 version on version.gitlab.com
    • Ensure someone tweets about the 11.1.0 release in the #releases channel
Edited by Alessio Caiazza