Release 10.6.0-rc2
Plan to cut Release 10.6.0-rc2 on 8th March 2018
Note RC2 is RC1 plus some critical fixes.
Tasks
RC2
- Follow steps to create a release candidate
-
Check the following list of critical issues/MRs which are to be included in
10.6.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-6-stable
into EE10-6-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 togithub
-
Sync master branches to dev
andgithub
, as the CHANGELOG will be automatically updated on master during tagging -
If needed, sync tags for dependencies ( gitlab-shell
,gitlab-workhorse
,gitlab-pages
,gitaly
) todev
andgithub
(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-6-stable-ee -- db/migrate db/post_migrate
=> -
In #releases
: I'm going to tag10.6.0-rc2
-
Tag the 10.6.0-rc2
version using therelease
task:# In the release-tools project: bundle exec rake "release[10.6.0-rc2]"
-
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.6.0-rc2
to staging.gitlab.com# In the takeoff project: bin/takeoff-deploy -e staging -v 10.6.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.6.0-rc2
has been deployed to staging -
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.6.0-rc2
to canary.gitlab.com# In the takeoff project: bin/takeoff-deploy -e canary -v 10.6.0-rc2.ee.0
-
Announce on the #releases
Slack channels:10.6.0-rc2
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.6.0-rc2. For status updates, please follow https://twitter.com/GitLabStatus"
- With downtime: 1 hour before
!tweet "We will be deploying GitLab EE 10.6.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.6.0-rc2 starting at X:Y UTC"
- With downtime: 1 hour before
-
On video call, deploy release 10.6.0-rc2
to GitLab.com# In the takeoff project: bin/takeoff-deploy -e production -v 10.6.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]"
-
Verify that packages appear on packages.gitlab.com
: EE & CE
-