Release 10.6.1

Preparation

Create preparation MRs for this version and add the links below:
```
# In the release-tools project:
bundle exec rake "patch_merge_request[10.6.1]"
```
Cherry-pick changes into preparation MRs following their instructions
Ensure the CE preparation MR has been fully merged into the EE counterpart
Merge the preparation branches
Cherry-pick remaining merge requests labeled ~"Pick into 10.6"
Check the following list of critical issues/MRs which are to be included in 10.6.1. Ensure each has made both CE and EE:
- REFERENCE_TO_MR_TO_PICK
Ensure builds are green on Omnibus CE stable branch and Omnibus EE stable branch

Packaging

Sync stable branches for CE, EE, and Omnibus to dev; CE and Omnibus to github
Check for any problematic migrations in EE, and paste the diff in a snippet: git diff v10.6.1-ee..10-6-stable-ee -- db/migrate db/post_migrate => https://gitlab.com/snippets/1706466

Tag the 10.6.1 version using the release task:

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

While waiting for packages to build, now is a good time to prepare the blog post. Look at previous MRs for examples. => gitlab-com/www-gitlab-com!10784 (merged)
Check progress of EE packages build and CE packages build

Deploy

All deploys require confirmation from a production team member before proceeding. Use !oncall prod to find who's on call and ping someone.

Warm up the packages on takeoff by running:

# In the takeoff project:
bin/takeoff-deploy -v 10.6.1-ee.0 -w

staging.gitlab.com

Get confirmation from a production team member to deploy staging

On video call, deploy 10.6.1 to staging.gitlab.com

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

Comment with the output of the migrations from the takeoff script in this issue

QA

Announce with an @product-team mention in the #product Slack channel: @product-team `10.6.1` has been deployed to staging.
Create a "QA Task" issue in the gitlab-org/release/tasks repo : #139 (closed)
Wait for the QA Task deadline to pass

canary.gitlab.com

Get confirmation from a production team member to deploy canary

On video call, deploy 10.6.1 to canary.gitlab.com

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

gitlab.com (production)

Get confirmation from a production team member to deploy production

If downtime is expected, publicly announce the deploy 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.6.1 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.6.1 starting at X:Y UTC, 15 mins of downtime expected"

On video call, deploy 10.6.1 to GitLab.com

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

Tweet in the #production channel that the deploy has finished:
- !tweet "GitLab EE 10.6.1 has been deployed."

Take notes of the time it took for the migrations to complete on the deploy to production:

# In the takeoff project
bundle exec rake "follow_migrations[production]"

 52.177.192.107 == 20180320182229 AddIndexesForUserActivityQueries: migrating =================
 52.177.192.107 -- index_exists?(:events, [:author_id, :project_id])
 52.177.192.107    -> 0.0091s
 52.177.192.107 -- index_exists?(:user_interacted_projects, :user_id)
 52.177.192.107    -> 0.0032s
 52.177.192.107 == 20180320182229 AddIndexesForUserActivityQueries: migrated (0.0125s) ========
 52.177.192.107

Release

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.6.1 version on https://version.gitlab.com
Deploy the blog post

Post a tweet about the 10.6.1 release in the #releases channel:

!tweet "GitLab 10.6.1 is now available: [BLOG_POST_URL] [DESCRIPTION_OF_CHANGES]"

References

gitlab.com

dev.gitlab.org

Edited Mar 28, 2018 by Filipa Lacerda