Release 10.5.4
-
Schedule the patch release by setting a Due date -
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.5" using this Merged MRs list -
Check the following list of critical issues/MRs which are to be included in 10.5.4
. Where appropriate, ensure each has made it into both CE and EE-
REFERENCE_TO_MR_TO_PICK
-
-
Make sure the Due date is up-to-date -
If you didn't merge CE into EE in the preparation branches, or if the CE stable branch had additional commits, merge CE 10-5-stable
into EE10-5-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 v10.5.3-ee..10-5-stable-ee -- db/migrate db/post_migrate
=> -
Make sure omnibus-gitlab/10-5-stable
CHANGELOG.md has an entry for each introduced change on Omnibus CE stable branch -
Make sure omnibus-gitlab/10-5-stable-ee
CHANGELOG.md has an entry for each introduced change on Omnibus EE stable branch -
Tag the 10.5.4
version using therelease
task:```sh # In the release-tools project: bundle exec rake "release[10.5.4]" ```
-
While waiting for packages to build, now is a good time to create the blog post MR. Look at previous MRs for examples. => BLOG_POST_MR -
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.5.4
to staging.gitlab.comsh # In the takeoff project: bin/takeoff-deploy -e staging -v 10.5.4-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. -
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. -
Create a "QA Task" issue in the gitlab-org/release/tasks repo. -
Wait for the QA Task deadline to pass. -
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.5.4
to canary.gitlab.comsh # In the takeoff project: bin/takeoff-deploy -e canary -v 10.5.4-ee.0
-
Get confirmation from a production team member to deploy production. Use !oncall prod
if needed to find who's on call. -
If downtime is expected, publicly [announce the deployment] 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.5.4-rc2 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.5.4-rc2 starting at X:Y UTC, 15 mins of downtime expected"
-
On video call, deploy release 10.5.4
to GitLab.comsh # In the takeoff project: bin/takeoff-deploy -e production -v 10.5.4-ee.0
-
Tweet in the #production
channel that the deployment has finished:!tweet "GitLab EE 10.5.4 has been deployed."
-
Create the 10.5.4
version on https://version.gitlab.com -
Deploy the blog post -
Tweet (prepare the Tweet text below or paste the tweet URL instead) in the #releases
channel:``` !tweet "GitLab 10.5.4 is released! BLOG_POST_URL DESCRIPTION OF THE CHANGES" ```
-
Add omnibus-gitlab/10.5.4+ce.0
CHANGELOG.md items toomnibus-gitlab/master
CHANGELOG.md
For references:
On gitlab.com
- https://gitlab.com/gitlab-org/gitlab-ce/commits/10-5-stable
- https://gitlab.com/gitlab-org/gitlab-ee/commits/10-5-stable-ee
- https://gitlab.com/gitlab-org/omnibus-gitlab/commits/10-5-stable
- https://gitlab.com/gitlab-org/omnibus-gitlab/commits/10-5-stable-ee
On gitlab.org