Skip to content

Release 10.3

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.3" group label if it doesn't exist: https://gitlab.com/groups/gitlab-org/labels/new

    • Title: Pick into 10.3

    • Description:

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

  • In #development:

    @channel

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

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

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

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

  • In Omnibus create both 10-3-stable and 10-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: 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 (migration problems - replication lag)

  • Follow the Creating RC1 guide:
    • Create MR on CE master updating the "Installation from Source" guide, creating the "Update" guides !15899 (merged) !15900 (merged)
    • Create MR on EE master creating the "CE to EE" guides gitlab-ee!3754
    • Create MR on CE master updating the gitignore and license templates !15901 (merged)
    • Create MR on CE master updating the dependencies license list !15905 (merged)
    • Ensure above MRs are merged and marked ~"Pick into 10.3"
  • 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.3" using this Merged MRs list

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

    • If you didn't merge CE into EE in the preparation branches, or if the CE stable branch had additional commits, merge CE 10-3-stable into EE 10-3-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-3-stable-ee -- db/migrate db/post_migrate => https://gitlab.com/snippets/1688824

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

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

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

    • Check progress of EE packages build and CE packages build

    • In #production: I'm going to deploy 10.3.0-rc1 to staging

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

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

    • Due to https://gitlab.com/gitlab-com/infrastructure/issues/3367, ask #production to verify that chef-server has an updated version role for the staging environment and trigger chef-client manually to make sure it still has the correct version.

    • Announce with an @channel mention on the following Slack channels that 10.3.0-rc1 has been deployed to staging, and include a link to the draft release post: #releases, #product

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

    • In #production: I'm going to deploy 10.3.0-rc1 to canary

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

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

    • Announce with an @channel mention on the following Slack channels that 10.3.0-rc1 has been deployed to canary, and include a link to the draft release post: #releases, #product

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

    • In #production: I'm going to deploy 10.3.0-rc1 to production

    • Get confirmation from a production team member. 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.3.0-rc1. For status updates, please follow https://twitter.com/GitLabStatus" * With downtime: 1 hour before !tweet "We will be deploying GitLab EE 10.3.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.3.0-rc1 starting at X:Y UTC"

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

      # In the takeoff project:
bin/takeoff-deploy -e production -v 10.3.0-rc1.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]"

    • 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.3.0-rc1 release in the #production channel:

      !tweet "GitLab 10.3.0-rc1 is available: https://packages.gitlab.com/gitlab/unstable
Use at your own risk."

RC2 (migration problems - replication lag)

  • 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.3" using this Merged MRs list~~

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

  • Pick https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15997 into stables

  • Follow the Creating subsequent RCs guide for 10.3.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-3-stable into EE 10-3-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.3.0-rc1-ee..10-3-stable-ee -- db/migrate db/post_migrate => https://gitlab.com/snippets/1689578

    • In #releases: I'm going to tag 10.3.0-rc2

    • Tag the 10.3.0-rc2 version using the release task:

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

  • Check progress of EE packages build and CE packages build

  • In #production: I'm going to deploy 10.3.0-rc2 to staging

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

  • On video call, deploy release 10.3.0-rc2 to staging.gitlab.com

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

  • Announce with an @channel mention on the following Slack channels that 10.3.0-rc2 has been deployed to staging, and include a link to the draft release post: #releases, #product

  • Wait for confirmation from @bjgopinath that testing succeeded on staging and the release can proceed (skipped, only 1 migration difference)

  • In #production: I'm going to deploy 10.3.0-rc2 to canary

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

  • On video call, deploy release 10.3.0-rc2 to canary.gitlab.com

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

  • Announce with an @channel mention on the following Slack channels that 10.3.0-rc2 has been deployed to staging, and include a link to the draft release post: #releases, #product

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

  • In #production: I'm going to deploy 10.3.0-rc2 to production

  • Get confirmation from a production team member. 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.3.0-rc2.
For status updates, please follow https://twitter.com/GitLabStatus"
    • With downtime: 1 hour before
    !tweet "We will be deploying GitLab EE 10.3.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.3.0-rc2 starting at X:Y UTC"

  • On video call, deploy release 10.3.0-rc2 to GitLab.com

    # In the takeoff project:
bin/takeoff-deploy -e production -v 10.3.0-rc2.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]"

  • 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.3.0-rc2 release:

    !tweet "GitLab 10.3.0-rc2 is available: https://packages.gitlab.com/gitlab/unstable
Use at your own risk."

RC3 (simply RC1 + RC2 + migration removals)

  • 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.3" using this Merged MRs list

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

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

    • If you didn't merge CE into EE in the preparation branches, or if the CE stable branch had additional commits, merge CE 10-3-stable into EE 10-3-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.3.0-rc2-ee..10-3-stable-ee -- db/migrate db/post_migrate =>

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

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

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

  • Check progress of EE packages build and CE packages build

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

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

  • On video call, deploy release 10.3.0-rc3 to staging.gitlab.com

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

  • Announce with an @channel mention on the following Slack channels that 10.3.0-rc3> has been deployed to staging, and include a link to the draft release post: #releases, #product

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

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

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

  • On video call, deploy release 10.3.0-rc3 to canary.gitlab.com

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

  • Announce with an @channel mention on the following Slack channels that 10.3.0-rc3 has been deployed to canary, and include a link to the draft release post: #releases, #product

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

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

  • Get confirmation from a production team member. 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.3.0-rc3.
For status updates, please follow https://twitter.com/GitLabStatus"
    • With downtime: 1 hour before
    !tweet "We will be deploying GitLab EE 10.3.0-rc3 starting at X:Y UTC, 15 mins of downtime expected"
    • Without downtime: 15 minutes before
    !tweet "We are about to deploy GitLab EE 10.3.0-rc3 starting at X:Y UTC"

  • On video call, deploy release 10.3.0-rc3 to GitLab.com

    # In the takeoff project:
bin/takeoff-deploy -e production -v 10.3.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]"

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

    !tweet "GitLab 10.3.0-rc3 is available: https://packages.gitlab.com/gitlab/unstable
Use at your own risk."

RC4

Preparation branches are named RC3 because it was meant to be a RC3 prepatation

  • 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.3" using this Merged MRs list

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

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

    • If you didn't merge CE into EE in the preparation branches, or if the CE stable branch had additional commits, merge CE 10-3-stable into EE 10-3-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.3.0-rc3-ee..10-3-stable-ee -- db/migrate db/post_migrate =>

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

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

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

  • Check progress of EE packages build and CE packages build

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

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

  • On video call, deploy release 10.3.0-rc4 to staging.gitlab.com

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

  • Announce with an @channel mention on the following Slack channels that 10.3.0-rc3> has been deployed to staging, and include a link to the draft release post: #releases, #product

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

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

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

  • On video call, deploy release 10.3.0-rc4 to canary.gitlab.com

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

  • Announce with an @channel mention on the following Slack channels that 10.3.0-rc4 has been deployed to canary, and include a link to the draft release post: #releases, #product

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

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

  • Get confirmation from a production team member. 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.3.0-rc4.
For status updates, please follow https://twitter.com/GitLabStatus"
    • With downtime: 1 hour before
    !tweet "We will be deploying GitLab EE 10.3.0-rc4 starting at X:Y UTC, 15 mins of downtime expected"
    • Without downtime: 15 minutes before
    !tweet "We are about to deploy GitLab EE 10.3.0-rc4 starting at X:Y UTC"

  • On video call, deploy release 10.3.0-rc4 to GitLab.com

    # In the takeoff project:
bin/takeoff-deploy -e production -v 10.3.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]"

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

    !tweet "GitLab 10.3.0-rc3 is available: https://packages.gitlab.com/gitlab/unstable
Use at your own risk."

RC5

  • 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.3" using this Merged MRs list~~

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

  • Pick https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15997 into stables

  • Follow the Creating subsequent RCs guide for 10.3.0-rc5:

    • If you didn't merge CE into EE in the preparation branches, or if the CE stable branch had additional commits, merge CE 10-3-stable into EE 10-3-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.3.0-rc1-ee..10-3-stable-ee -- db/migrate db/post_migrate =>

    • In #releases: I'm going to tag 10.3.0-rc5

    • Tag the 10.3.0-rc5 version using the release task:

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

  • Check progress of EE packages build and CE packages build

  • In #production: I'm going to deploy 10.3.0-rc5 to staging

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

  • On video call, deploy release 10.3.0-rc5 to staging.gitlab.com

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

  • Announce with an @channel mention on the following Slack channels that 10.3.0-rc5> has been deployed to staging, and include a link to the draft release post: #releases, #product

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

  • In #production: I'm going to deploy 10.3.0-rc5 to canary

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

  • On video call, deploy release 10.3.0-rc5 to canary.gitlab.com

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

  • Announce with an @channel mention on the following Slack channels that 10.3.0-rc5 has been deployed to canary, and include a link to the draft release post: #releases, #product

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

  • In #production: I'm going to deploy 10.3.0-rc5 to production

  • Get confirmation from a production team member. 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.3.0-rc5.
For status updates, please follow https://twitter.com/GitLabStatus"
    • With downtime: 1 hour before
    !tweet "We will be deploying GitLab EE 10.3.0-rc5 starting at X:Y UTC, 15 mins of downtime expected"
    • Without downtime: 15 minutes before
    !tweet "We are about to deploy GitLab EE 10.3.0-rc5 starting at X:Y UTC"

  • On video call, deploy release 10.3.0-rc5 to GitLab.com

    # In the takeoff project:
bin/takeoff-deploy -e production -v 10.3.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]"

  • 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.3.0-rc5 release:

    !tweet "GitLab 10.3.0-rc5 is available: https://packages.gitlab.com/gitlab/unstable
Use at your own risk."

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-3-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.3" using this [Merged MRs list]~~
- ~~Check the following list of critical issues/MRs which are to be included in `10.3.0`. Ensure each has made both CE and EE~~
- [ ] Pick https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15997 into stables
- Follow the [Creating subsequent RCs] guide for `10.3.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-3-stable` into EE `10-3-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.3.0-rc1-ee..10-3-stable-ee -- db/migrate db/post_migrate` =>
  - [ ] In `#releases`: I'm going to tag `10.3.0-rc2`
  - [ ] Tag the `10.3.0-rc2` version using the [`release` task]:

        ```sh
        # In the release-tools project:
        bundle exec rake "release[10.3.0-rc2]"
        ```
- [ ] Check progress of [EE packages build](https://dev.gitlab.org/gitlab/omnibus-gitlab/commits/10.3.0+rc2.ee.0) and [CE packages build](https://dev.gitlab.org/gitlab/omnibus-gitlab/commits/10.3.0+rc2.ce.0)
- [ ] In `#production`: I'm going to deploy `10.3.0-rc2` to staging
- [ ] Get confirmation from a production team member. Use `!oncall prod` if needed to find who's on call.
- [ ] On video call, [deploy] release [`10.3.0-rc2`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_10.3.0-rc2.ee.0_amd64.deb) to [staging.gitlab.com]
    ```sh
    # In the takeoff project:
    bin/takeoff-deploy -e staging -v 10.3.0-rc2.ee.0
    ```
- [ ] Announce with an `@channel` mention on the following Slack channels that `10.3.0-rc2>` has been deployed to staging, and include a link to the draft release post: `#releases`, `#product`
- [ ] Wait for confirmation from [`@bjgopinath`](https://gitlab.com/bjgopinath) that testing succeeded on staging and the release can proceed
- [ ] In `#production`: I'm going to deploy `10.3.0-rc2` to canary
- [ ] Get confirmation from a production team member. Use `!oncall prod` if needed to find who's on call.
- [ ] On video call, [deploy] release [`10.3.0-rc2`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_10.3.0-rc2.ee.0_amd64.deb) to [canary.gitlab.com]
    ```sh
    # In the takeoff project:
    bin/takeoff-deploy -e canary -v 10.3.0-rc2.ee.0
    ```
- [ ] Announce with an `@channel` mention on the following Slack channels that `10.3.0-rc2` has been deployed to canary, and include a link to the draft release post: `#releases`, `#product`
- [ ] Wait for confirmation from [`@bjgopinath`](https://gitlab.com/bjgopinath) that testing succeeded on canary and the release can proceed
- [ ] In `#production`: I'm going to deploy `10.3.0-rc2` to production
- [ ] Get confirmation from a production team member. 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.3.0-rc2.
    For status updates, please follow https://twitter.com/GitLabStatus"
    ```
    * With downtime: 1 hour before
    ```
    !tweet "We will be deploying GitLab EE 10.3.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.3.0-rc2 starting at X:Y UTC"
    ```
- [ ] On video call, [deploy] release [`10.3.0-rc2`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_10.3.0-rc2.ee.0_amd64.deb) to GitLab.com
    ```sh
    # In the takeoff project:
    bin/takeoff-deploy -e production -v 10.3.0-rc2.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]"
    ```
- [ ] 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.3.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.3.0-rc2` release:

    ```
    !tweet "GitLab 10.3.0-rc2 is available: https://packages.gitlab.com/gitlab/unstable
    Use at your own risk."
    ```

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.3.0-rc21]"

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

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

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

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

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

      • Announce with an @channel mention on the following Slack channels that 10.3.0-rc21 has been deployed to staging, and include a link to the draft release post: #releases, #product

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

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

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

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

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

      • Announce with an @channel mention on the following Slack channels that 10.3.0-rc21 has been deployed to canary, and include a link to the draft release post: #releases, #product

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

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

      • Get confirmation from a production team member. 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.3.0-rc2.
For status updates, please follow https://twitter.com/GitLabStatus"
        • With downtime: 1 hour before
        !tweet "We will be deploying GitLab EE 10.3.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.3.0-rc2 starting at X:Y UTC"

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

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

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

        !tweet "GitLab 10.3.0-rc21 is available: https://packages.gitlab.com/gitlab/unstable
Use at your own risk."

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

  • Before 12:00 UTC:

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

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

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

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

    • In #production: I'm going to deploy 10.3.0 to canary

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

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

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

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

    • Get confirmation from a production team member. 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.3.0. For status updates, please follow https://twitter.com/GitLabStatus" * With downtime: 1 hour before !tweet "We will be deploying GitLab EE 10.3.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.3.0 starting at X:Y UTC"

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

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

    • Create the first patch issue using the patch_issue task:

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

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

  • At 15:00 UTC:

Edited by Oswaldo Ferreira