Release 10.6.0-rc1
Tasks
-
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-6-stable
from CEmaster
manually -
Create branch 10-6-stable-ee
from EEmaster
manually -
In Omnibus create both 10-6-stable
and10-6-stable-ee
frommaster
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 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
=>
Expand for migrate post-migrate diff for 10.6.0-rc1
-
In #releases
: I'm going to tag10.6.0-rc1
-
Tag the 10.6.0-rc1
version using therelease
task:# In the release-tools project: bundle exec rake "release[10.6.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.6.0-rc1
to staging.gitlab.com# In the takeoff project: bin/takeoff-deploy -e staging -v 10.6.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.
DB migrate logs for staging deployment for 10.6.0-rc1:
Overall time for migrations: 38 mins
Expand for output related to 10.6.0-rc1.ee.0 migration timings on staging
-
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.6.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-team10.6.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
Notes
- RC1 was prepared early due to:
- #62 (closed)