Release 10.1

First working day after 7th

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

  • In #development:

    @channel

I am about to create the `10-1-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-1-stable`.

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

  • Create branch 10-1-stable from CE master manually

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

  • In Omnibus create both 10-1-stable and 10-1-stable-ee from master manually

  • Merge GitLab CE into EE on the stable branches

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

RC1

RC2

Replaced by https://gitlab.com/gitlab-org/gitlab-ce/issues/39191

RC3

  • Create preperation 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 Stable for the current milestone using the Pick into Stable 10.1 merged merge requests page

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

    • REFERENCE_TO_MR_TO_PICK

  • Follow the Creating subsequent RCs guide for 10.1.0-rc3:

    • Merge CE 10-1-stable into EE 10-1-stable-ee 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)

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

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

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

    • Make sure to announce the deployment on Twitter and GitLab.com

      • With downtime: 1 hour before
      • Without downtime: 15 minutes before

    • In #releases: I'm going to tag 10.1.0-rc3

    • Tag the 10.1.0-rc3 version using the release task:

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

  • Check progress of EE packages build and CE packages build

  • In #production: I'm going to deploy 10.1.0-rc3 to staging

  • On video call, deploy release 10.1.0-rc3 to staging.gitlab.com sh # In the takeoff project: bundle exec rake "deploy[staging, 10.1.0-rc3.ee.0]"

  • If needed, in #production: I'm going to deploy 10.1.0-rc3 to canary

  • If needed, deploy release 10.1.0-rc3 to canary.gitlab.com sh # In the takeoff project: bundle exec rake "deploy[canary, 10.1.0-rc3.ee.0]"

    • Make sure to announce the deployment on Twitter and GitLab.com
      • With downtime: 1 hour before
      • Without downtime: 15 minutes before

  • In #production: I'm going to deploy 10.1.0-rc3 to production

  • On video call, deploy release 10.1.0-rc3 to GitLab.com sh # In the takeoff project: bundle exec rake "deploy[production, 10.1.0-rc3.ee.0]"

  • 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]"

  • Publicly announce the deploy on Twitter, at this point the deploy alert banner on GitLab.com should already be up.

  • 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.1.0-rc3 release:

    ```
GitLab 10.1.0-rc3 is available: https://packages.gitlab.com/gitlab/unstable
Use at your own risk. Please link regressions issues from
https://gitlab.com/gitlab-org/gitlab-ce/issues/39174
```

RC4

  • Create preperation 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 Stable for the current milestone using the Pick into Stable 10.1 merged merge requests page

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

    • REFERENCE_TO_MR_TO_PICK

  • Follow the Creating subsequent RCs guide for 10.1.0-rc4:

    • Merge CE 10-1-stable into EE 10-1-stable-ee 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)

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

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

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

    • Make sure to announce the deployment on Twitter and GitLab.com

      • With downtime: 1 hour before
      • Without downtime: 15 minutes before

    • In #releases: I'm going to tag 10.1.0-rc4

    • Tag the 10.1.0-rc4 version using the release task:

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

  • Check progress of EE packages build and CE packages build

  • In #production: I'm going to deploy 10.1.0-rc4 to staging

  • On video call, deploy release 10.1.0-rc4 to staging.gitlab.com sh # In the takeoff project: bundle exec rake "deploy[staging, 10.1.0-rc4.ee.0]"

  • If needed, in #production: I'm going to deploy 10.1.0-rc4 to canary

  • If needed, deploy release 10.1.0-rc4 to canary.gitlab.com sh # In the takeoff project: bundle exec rake "deploy[canary, 10.1.0-rc4.ee.0]"

    • Make sure to announce the deployment on Twitter and GitLab.com
      • With downtime: 1 hour before
      • Without downtime: 15 minutes before

  • In #production: I'm going to deploy 10.1.0-rc4 to production

  • On video call, deploy release 10.1.0-rc4 to GitLab.com sh # In the takeoff project: bundle exec rake "deploy[production, 10.1.0-rc4.ee.0]"

  • 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]"

  • Publicly announce the deploy on Twitter, at this point the deploy alert banner on GitLab.com should already be up.

  • 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.1.0-rc4 release:

    ```
GitLab 10.1.0-rc4 is available: https://packages.gitlab.com/gitlab/unstable
Use at your own risk. Please link regressions issues from
https://gitlab.com/gitlab-org/gitlab-ce/issues/39174
```

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-1-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).

#### RC5

- [ ] Create preperation 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 Stable` for the current
milestone using the
[`Pick into Stable` 10.1 merged merge requests] page
- Check the following list of critical issues/MRs which are to be included in `10.1.0`. Ensure each has made both CE and EE
  - [ ] REFERENCE_TO_MR_TO_PICK
- Follow the [Creating subsequent RCs] guide for `10.1.0-rc5`:
  - [ ] Merge CE `10-1-stable` into EE `10-1-stable-ee` 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)
  - [ ] Check for any problematic migrations in EE (EE migrations include CE ones), and paste the diff in a snippet: `git diff v10.1.0-rc1-ee..10-1-stable-ee -- db/migrate db/post_migrate` =>
  - [ ] Ensure builds are green on [CE stable branch] and [EE stable branch]
  - [ ] Ensure builds are green on [Omnibus CE stable branch] and [Omnibus EE stable branch]
  - [ ] Make sure to [announce the deployment] on Twitter and GitLab.com
      * With downtime: 1 hour before
      * Without downtime: 15 minutes before
  - [ ] In `#releases`: I'm going to tag `10.1.0-rc5`
  - [ ] Tag the `10.1.0-rc5` version using the [`release` task]:

        ```sh
        # In the release-tools project:
        bundle exec rake "release[10.1.0-rc5]"
        ```
- [ ] Check progress of [EE packages build](https://dev.gitlab.org/gitlab/omnibus-gitlab/commits/10.1.0+rc5.ee.0) and [CE packages build](https://dev.gitlab.org/gitlab/omnibus-gitlab/commits/10.1.0+rc5.ce.0)
- [ ] In `#production`: I'm going to deploy `10.1.0-rc5` to staging
- [ ] On video call, [deploy] release [`10.1.0-rc5`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_10.1.0-rc5.ee.0_amd64.deb) to [staging.gitlab.com]
      ```sh
      # In the takeoff project:
      bundle exec rake "deploy[staging, 10.1.0-rc5.ee.0]"
      ```
- [ ] If needed, in `#production`: I'm going to deploy `10.1.0-rc5` to canary
- [ ] If needed, [deploy] release [`10.1.0-rc5`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_10.1.0-rc5.ee.0_amd64.deb) to [canary.gitlab.com]
      ```sh
      # In the takeoff project:
      bundle exec rake "deploy[canary, 10.1.0-rc5.ee.0]"
      ```
  - [ ] Make sure to [announce the deployment] on Twitter and GitLab.com
      * With downtime: 1 hour before
      * Without downtime: 15 minutes before
- [ ] In `#production`: I'm going to deploy `10.1.0-rc5` to production
- [ ] On video call, [deploy] release [`10.1.0-rc5`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_10.1.0-rc5.ee.0_amd64.deb) to GitLab.com
      ```sh
      # In the takeoff project:
      bundle exec rake "deploy[production, 10.1.0-rc5.ee.0]"
      ```
- [ ] 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]"
      ```
- [ ] Publicly [announce the deploy on Twitter], at this point the deploy alert banner on GitLab.com should already be up.
- [ ] 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.1.0-rc5)
- [ ] 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.1.0-rc5` release:

      ```
      GitLab 10.1.0-rc5 is available: https://packages.gitlab.com/gitlab/unstable
      Use at your own risk. Please link regressions issues from
      https://gitlab.com/gitlab-org/gitlab-ce/issues/39174
      ```

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,

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

      • Check progress of EE packages build and CE packages build

      • In #production: I'm going to deploy 10.1.0-rc21 to staging

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

        # In the takeoff project:
bundle exec rake "deploy[staging, 10.1.0-rc21.ee.0]"

      • If needed, in #production: I'm going to deploy 10.1.0-rc21 to canary

      • If needed, deploy release 10.1.0-rc21 to canary.gitlab.com

        # In the takeoff project:
bundle exec rake "deploy[canary, 10.1.0-rc21.ee.0]"

      • In #production: I'm going to deploy 10.1.0-rc21 to production

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

        # In the takeoff project:
bundle exec rake "deploy[production, 10.1.0-rc21.ee.0]"

      • Publicly announce the deploy on Twitter, at this point the deploy alert banner on GitLab.com should already be up.

      • 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.1.0-rc21 release:

        GitLab 10.1.0-rc21 is available: https://packages.gitlab.com/gitlab/unstable
Use at your own risk. Please link regressions issues from
https://gitlab.com/gitlab-org/gitlab-ce/issues/39174

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

    • 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)
    • 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
    • If at this time final release is not ready for tagging, notify the CTO

  • Before 10:00 UTC:

  • Before 12:00 UTC:

    • In #production: I'm going to deploy 10.1.0 to staging

    • Do the deploy of 10.1.0 to staging.gitlab.com

    • In #production: I'm going to deploy 10.1.0 to production

    • Publicly announce the deploy on Twitter, at this point the deploy alert banner on GitLab.com should already be up.

    • Do the deploy of 10.1.0 to GitLab.com

    • Create the first patch issue using the patch_issue task:

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

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

  • At 15:00 UTC:

Edited by Lin Jen-Shin