Skip to content

Release 10.5

First working day after 7th

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

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

    • Title: Pick into 10.5

    • Description:

      Merge requests to cherry-pick into the `10-5-stable` branch. Remove the label once picked.

    • Color: #00c8ca

  • In #development:

    @channel

I am about to create the `10-5-stable` branch. Everything merged into `master`
after this point will go into next month's release. Only regression and security fixes
will be cherry-picked into `10-5-stable`.

Please ensure that merge requests have the correct milestone (`10.5` for this release)
and the `Pick into 10.5` 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

  • 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 10-5-stable from CE master manually

  • Create branch 10-5-stable-ee from EE master manually

  • In Omnibus create both 10-5-stable and 10-5-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: CE, EE, and Omnibus to dev, CE and Omnibus to github

  • Sync master branches to dev and github, 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 and github (when applicable. Builds should fail if this is needed.)

RC1

  • Follow the Creating RC1 guide:
    • Create MR on CE master updating the "Installation from Source" guide, creating the "Update" guides
    • Create MR on EE master creating the "CE to EE" guides
    • Create MR on CE master updating the .gitignore, .gitlab-ci.yml, and Dockerfile templates
    • Create MR on CE master updating the dependencies license list
    • Ensure above MRs are merged and marked ~"Pick into 10.5"
  • Follow steps to create a release candidate

    • Create preparation MRs by following the instructions in release-tools.

    • Cherry-pick changes into preparation MRs following their instructions

    • Cherry-pick remaining merge requests labeled ~"Pick into 10.5" using this Merged MRs list

    • Check the following list of critical issues/MRs which are to be included in 10.5.0. Ensure each has made both CE and EE

      • REFERENCE_TO_MR_TO_PICK

    • If you didn't merge CE into EE in the preparation branches, or if the CE stable branch had additional commits, merge CE 10-5-stable into EE 10-5-stable-ee following the Merging a CE stable branch into its EE counterpart guide. (In general this should be unnecessary.)

    • Ensure builds are green on Omnibus CE stable branch and Omnibus EE stable branch

    • Sync stable branches: CE, EE, and Omnibus to dev, CE and Omnibus to github

    • Sync master branches to dev and github, 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 and github (when applicable. Builds should fail if this is needed.)

    • Check for any problematic migrations in EE (EE migrations include CE ones), and paste the diff in a snippet: git diff LATEST_PATCH_TAG-ee..10-5-stable-ee -- db/migrate db/post_migrate =>

    • In #releases: I'm going to tag 10.5.0-rc1

    • Tag the 10.5.0-rc1 version using the release task:

      ```sh
# In the release-tools project:
bundle exec rake "release[10.5.0-rc1]"
```

    • Check progress of EE packages build and CE packages build

    • Get confirmation from a production team member to deploy staging. Use !oncall prod if needed to find who's on call.

    • On video call, deploy release 10.5.0-rc1 to staging.gitlab.com sh # In the takeoff project: bin/takeoff-deploy -e staging -v 10.5.0-rc1.ee.0

    • Share the output of the migrations from the takeoff script in this issue via a snippet. Flag any migrations that take more than 5 minutes to run.

    • Make sure that the database migrations complete in a timely manner. If you see a migration taking too long in staging, stop right there and ping @db-team in Slack. What you're witnessing has the potential to take down production for a long time. The statement "Don't worry: it'll be faster in production" is a false myth that has been disproven every single time that this has happened in the past.

    • Announce on the #releases Slack channels: 10.5.0-rc1 has been deployed to staging. Blog post draft: MERGE_REQUEST_URL

    • Announce with an @product-team mention on the #product Slack channel: @product-team 10.5.0-rc1 has been deployed to staging. Blog post draft: MERGE_REQUEST_URL

    • Wait for confirmation from @bjgopinath that testing succeeded on staging and the release can proceed

    • Get confirmation from a production team member to deploy canary. Use !oncall prod if needed to find who's on call.

    • On video call, deploy release 10.5.0-rc1 to canary.gitlab.com sh # In the takeoff project: bin/takeoff-deploy -e canary -v 10.5.0-rc1.ee.0

    • Announce on the #releases Slack channels: 10.5.0-rc1 has been deployed to canary. Blog post draft: MERGE_REQUEST_URL

    • Wait for confirmation from @bjgopinath that testing succeeded on canary and the release can proceed

    • Get confirmation from a production team member to deploy production. Use !oncall prod if needed to find who's on call.

    • Publicly announce the deployment on Twitter and with the GitLab.com deploy alert banner in the #production channel !broadcast --start X:Y --end A:B "We are currently deploying GitLab EE 10.5.0-rc1. For status updates, please follow https://twitter.com/GitLabStatus" * With downtime: 1 hour before !tweet "We will be deploying GitLab EE 10.5.0-rc1 starting at X:Y UTC, 15 mins of downtime expected" * Without downtime: 15 minutes before !tweet "We are about to deploy GitLab EE 10.5.0-rc1 starting at X:Y UTC"

    • On video call, deploy release 10.5.0-rc1 to GitLab.com

      # In the takeoff project:
bin/takeoff-deploy -e production -v 10.5.0-rc1.ee.0

    • Tweet in the #production channel that the deployment has finished:

      !tweet "GitLab EE 10.5.0-rc1 has been deployed."

    • Take notes of the time it took for the migrations to complete on the deployment to production.

      # On the takeoff repo
bundle exec rake "follow_migrations[production]"

    • From the build pipeline, manually publish public packages

    • Verify that packages appear on packages.gitlab.com: EE & CE

    • Verify that Docker images appear on hub.docker.com: EE / CE

    • Post a tweet about the 10.5.0-rc1 release in the #releases channel:

      !tweet "GitLab 10.5.0-rc1 is available: https://packages.gitlab.com/gitlab/unstable
This is a release candidate, we'll release 10.5 on the 22nd of this month."

QA

  • Determine QA person and notify this person: MENTION_THIS_PERSON_HERE
  • Do QA and fix anything coming out of it: LINK_TO_QA_ISSUE

Anytime after RC1 but before 22nd

  • Update the [blog post] barometer section with the migration types for this release, including the time they took to complete.
  • Create another RC as needed.

Keep in mind that:

  1. After feature freeze only regression and security fixes can be cherry-picked into 10-5-stable.
  2. Last RC should point to the same commit as the final release.

Copy-paste the tasks below for any other RCs (be sure to update the RC number).

#### RC2

- [ ] Create preparation MRs by following the [instructions in release-tools](https://gitlab.com/gitlab-org/release-tools/blob/master/doc/picking-into-merge-requests.md).
- [ ] Cherry-pick changes into preparation MRs following their instructions
- [ ] Cherry-pick remaining merge requests labeled ~"Pick into 10.5" using this [Merged MRs list]
- Check the following list of critical issues/MRs which are to be included in `10.5.0`. Ensure each has made both CE and EE
  - [ ] REFERENCE_TO_MR_TO_PICK
- Follow the [Creating subsequent RCs] guide for `10.5.0-rc2`:
  - [ ] If you didn't merge CE into EE in the preparation branches, or if the CE stable branch had additional commits, merge CE `10-5-stable` into EE `10-5-stable-ee` following the [Merging a CE stable branch into its EE counterpart] guide. (In general this should be unnecessary.)
  - [ ] Ensure builds are green on [Omnibus CE stable branch] and [Omnibus EE stable branch]
  - [ ] Sync stable branches: CE, EE, and Omnibus to `dev`, CE and Omnibus to `github`
  - [ ] Sync master branches to `dev` and `github`, 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` and `github` (when applicable. Builds should fail if this is needed.)
  - [ ] Check for any problematic migrations in EE (EE migrations include CE ones), and paste the diff in a snippet: `git diff v10.5.0-rc1-ee..10-5-stable-ee -- db/migrate db/post_migrate` =>
  - [ ] In `#releases`: I'm going to tag `10.5.0-rc2`
  - [ ] Tag the `10.5.0-rc2` version using the [`release` task]:

        ```sh
        # In the release-tools project:
        bundle exec rake "release[10.5.0-rc2]"
        ```
- [ ] Check progress of [EE packages build](https://dev.gitlab.org/gitlab/omnibus-gitlab/commits/10.5.0+rc2.ee.0) and [CE packages build](https://dev.gitlab.org/gitlab/omnibus-gitlab/commits/10.5.0+rc2.ce.0)
- [ ] Get confirmation from a production team member to deploy staging. Use `!oncall prod` if needed to find who's on call.
- [ ] On video call, [deploy] release [`10.5.0-rc2`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_10.5.0-rc2.ee.0_amd64.deb) to [staging.gitlab.com]
    ```sh
    # In the takeoff project:
    bin/takeoff-deploy -e staging -v 10.5.0-rc2.ee.0
    ```
- [ ] Share the output of the migrations from the takeoff script in this issue via a snippet. Flag any migrations that take more than 5 minutes to run.
- [ ] Announce on the `#releases` Slack channels: `10.5.0-rc2` has been deployed to staging. Blog post draft: MERGE_REQUEST_URL
- [ ] Announce with an `@product-team` mention on the `#product` Slack channel: @product-team `10.5.0-rc2` has been deployed to staging. Blog post draft: MERGE_REQUEST_URL
- [ ] Wait for confirmation from [`@bjgopinath`](https://gitlab.com/bjgopinath) that testing succeeded on staging and the release can proceed
- [ ] Get confirmation from a production team member to deploy canary. Use `!oncall prod` if needed to find who's on call.
- [ ] On video call, [deploy] release [`10.5.0-rc2`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_10.5.0-rc2.ee.0_amd64.deb) to [canary.gitlab.com]
    ```sh
    # In the takeoff project:
    bin/takeoff-deploy -e canary -v 10.5.0-rc2.ee.0
    ```
- [ ] Announce on the `#releases` Slack channels: `10.5.0-rc2` has been deployed to canary. Blog post draft: MERGE_REQUEST_URL
- [ ] Wait for confirmation from [`@bjgopinath`](https://gitlab.com/bjgopinath) that testing succeeded on canary and the release can proceed
- [ ] Get confirmation from a production team member to deploy production. Use `!oncall prod` if needed to find who's on call.
- [ ] If downtime is expected, publicly [announce the deployment] on Twitter and with the GitLab.com deploy alert banner in the `#production` channel, 1 hour in advance
    ```
    !broadcast --start X:Y --end A:B "We will deploying GitLab EE 10.5.0-rc2 starting at X:Y. GitLab will be unavailable for Z minutes.
    For status updates, please follow https://twitter.com/GitLabStatus"
    ```
    ```
    !tweet "We will be deploying GitLab EE 10.5.0-rc2 starting at X:Y UTC, 15 mins of downtime expected"
    ```
- [ ] On video call, [deploy] release [`10.5.0-rc2`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_10.5.0-rc2.ee.0_amd64.deb) to GitLab.com
    ```sh
    # In the takeoff project:
    bin/takeoff-deploy -e production -v 10.5.0-rc2.ee.0
    ```
- [ ] Tweet in the `#production` channel that the deployment has finished:
      ```
      !tweet "GitLab EE 10.5.0-rc2 has been deployed."
      ```
- [ ] Take notes of the time it took for the migrations to complete on the deployment to production.
    ```
    # On the takeoff repo
    bundle exec rake "follow_migrations[production]"
    ```
- [ ] From the [build pipeline], [manually publish public packages]
- [ ] Verify that packages appear on `packages.gitlab.com`: [EE & CE](https://packages.gitlab.com/app/gitlab/unstable/search?q=10.5.0-rc2)
- [ ] Verify that Docker images appear on `hub.docker.com`: [EE](https://hub.docker.com/r/gitlab/gitlab-ee/tags) / [CE](https://hub.docker.com/r/gitlab/gitlab-ce/tags)
- [ ] Post a [tweet about] the `10.5.0-rc2` release in the `#releases` channel:

    ```
    !tweet "GitLab 10.5.0-rc2 is available: https://packages.gitlab.com/gitlab/unstable
    This is a release candidate, we'll release 10.5 on the 22nd of this month."
    ```

21st final RC

  • Before 13:00 UTC:

    • Final RC is ready for tagging. Including changes at this stage requires signoff from VP of Eng.

      • 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

      • In #releases: I'm going to tag final RC release

      • Replace XX in the tasks below with the RC version number:

      • Tag the final RC version using the release task,

        # In the release-tools project:
bundle exec rake "release[10.5.0-rc21]"

      • Check progress of [EE packages build] and [CE packages build]

      • Get confirmation from a production team member to deploy staging. Use !oncall prod if needed to find who's on call.

      • On video call, deploy release 10.5.0-rc21 to staging.gitlab.com

        # In the takeoff project:
bin/takeoff-deploy -e staging -v 10.5.0-rc21.ee.0

      • Announce on the #releases Slack channels: 10.5.0-rc21 has been deployed to staging. Blog post draft: MERGE_REQUEST_URL

      • Announce with an @product-team mention on the #product Slack channel: @product-team 10.5.0-rc21 has been deployed to staging. Blog post draft: MERGE_REQUEST_URL

      • Wait for confirmation from @bjgopinath that testing succeeded on staging and the release can proceed

      • Get confirmation from a production team member to deploy canary. Use !oncall prod if needed to find who's on call.

      • On video call, deploy release 10.5.0-rc21 to canary.gitlab.com

        # In the takeoff project:
bin/takeoff-deploy -e canary -v 10.5.0-rc21.ee.0

      • Announce on the #releases Slack channels: 10.5.0-rc21 has been deployed to canary. Blog post draft: MERGE_REQUEST_URL

      • Wait for confirmation from @bjgopinath that testing succeeded on canary and the release can proceed

      • Get confirmation from a production team member to deploy production. Use !oncall prod if needed to find who's on call.

      • Publicly announce the deployment on Twitter and with the GitLab.com deploy alert banner in the #production channel

        !broadcast --start X:Y --end A:B "We are currently deploying GitLab EE 10.5.0-rc2.
For status updates, please follow https://twitter.com/GitLabStatus"
        • With downtime: 1 hour before
        !tweet "We will be deploying GitLab EE 10.5.0-rc2 starting at X:Y UTC, 15 mins of downtime expected"
        • Without downtime: 15 minutes before
        !tweet "We are about to deploy GitLab EE 10.5.0-rc2 starting at X:Y UTC"

      • On video call, deploy release 10.5.0-rc21 to GitLab.com

        # In the takeoff project:
bin/takeoff-deploy -e production -v 10.5.0-rc21.ee.0

      • Tweet in the #production channel that the deployment has finished:

        !tweet "GitLab EE 10.5.0-rc21 has been deployed."

      • From the build pipeline, manually publish public packages

      • Verify that packages appear on packages.gitlab.com: EE & CE

      • Verify that Docker images appear on hub.docker.com: EE / CE

      • Post a tweet about the 10.5.0-rc21 release in the #releases channel:

        !tweet "GitLab 10.5.0-rc21 is available: https://packages.gitlab.com/gitlab/unstable
This is a release candidate, we'll release 10.5 on the 22nd of this month."

  • At 15:00 UTC:

    • If the final RC is not tagged and deployed by this time, notify the Build Lead

  • At 20:00 UTC:

    • If the final RC is not tagged and deployed by this time, notify the VP of Engineering

22nd, the release day:

No new code is added to release that was not included in the last RC. This way we ensure the release does not introduce new regressions.

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

    • 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
    • Sync stable branches: CE, EE, and Omnibus to dev, CE and Omnibus to github
    • Sync master branches to dev and github, 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 and github (when applicable. Builds should fail if this is needed.)
    • If at this time final release is not ready for tagging, notify the CTO

  • Before 10:00 UTC:

    • In #releases: I'm going to tag 10.5.0

    • Tag the 10.5.0 version using the release task:

      ```sh
# In the release-tools project:
bundle exec rake "release[10.5.0]"
```

    • Check progress of [EE packages build] and [CE packages build]

  • Before 12:00 UTC:

    • Get confirmation from a production team member to deploy staging. Use !oncall prod if needed to find who's on call.

    • On video call, deploy release 10.5.0 to staging.gitlab.com

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

    • Announce on the #releases Slack channels: 10.5.0 has been deployed to staging. Blog post draft: MERGE_REQUEST_URL

    • Wait for confirmation from @bjgopinath that testing succeeded on staging and the release can proceed

    • Get confirmation from a production team member. Use !oncall prod if needed to find who's on call.

    • On video call, deploy release 10.5.0 to canary.gitlab.com

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

    • Announce on the #releases Slack channels: 10.5.0 has been deployed to canary. Blog post draft: MERGE_REQUEST_URL

    • Wait for confirmation from @bjgopinath that testing succeeded on canary and the release can proceed

    • Get confirmation from a production team member to deploy production. Use !oncall prod if needed to find who's on call.

    • Publicly announce the deployment on Twitter and with the GitLab.com deploy alert banner in the #production channel !broadcast --start X:Y --end A:B "We are currently deploying GitLab EE 10.5.0. For status updates, please follow https://twitter.com/GitLabStatus" * With downtime: 1 hour before !tweet "We will be deploying GitLab EE 10.5.0 starting at X:Y UTC, 15 mins of downtime expected" * Without downtime: 15 minutes before !tweet "We are about to deploy GitLab EE 10.5.0 starting at X:Y UTC"

    • On video call, deploy release 10.5.0 to GitLab.com

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

    • Tweet in the #production channel that the deployment has finished: !tweet "GitLab EE 10.5.0 has been deployed."

    • Create the first patch issue using the patch_issue task:

      ```sh
# In the release-tools project:
bundle exec rake "patch_issue[10.5.1]"
```

    • If at this point final release is not ready for public, notify the CEO

  • At 15:00 UTC:

    • Make sure that neither packages nor blog post get published before that time without approval by the marketing team.
    • From the build pipeline, manually publish public packages
    • Verify that packages appear on packages.gitlab.com: EE / CE
    • Verify that Docker images appear on hub.docker.com: EE / CE
    • Create the 10.5.0 version on https://version.gitlab.com
    • Ensure someone tweets about the 10.5.0 release in the #releases channel
Edited by Mark Fletcher