Release 10.4
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.4" group label if it doesn't exist: https://gitlab.com/groups/gitlab-org/labels/new -
Title:
Pick into 10.4
-
Description:
Merge requests to cherry-pick into the `10-4-stable` branch. Remove the label once picked.
-
Color:
#00c8ca
-
-
In #development
:@channel I am about to create the `10-4-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-4-stable`. Please ensure that merge requests have the correct milestone (`10.4` for this release) and the `Pick into 10.4` 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
-
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-4-stable
from CEmaster
manually -
Create branch 10-4-stable-ee
from EEmaster
manually -
In Omnibus create both 10-4-stable
and10-4-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.)
RC1
- Follow the Creating RC1 guide:
-
Create MR on CE master updating the "Installation from Source" guide, creating the "Update" guides -
Create MR on EE master creating the "CE to EE" guides -
Create MR on CE master updating the gitignore and license templates -
Create MR on CE master updating the dependencies license list -
Ensure above MRs are merged and marked ~"Pick into 10.4"
-
- 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.4" using this Merged MRs list -
Check the following list of critical issues/MRs which are to be included in
10.4.0
. Ensure each has made both CE and EE-
REFERENCE_TO_MR_TO_PICK
-
-
If you didn't merge CE into EE in the preparation branches, or if the CE stable branch had additional commits, merge CE 10-4-stable
into EE10-4-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-4-stable-ee -- db/migrate db/post_migrate
=> -
In #releases
: I'm going to tag10.4.0-rc1
-
Tag the 10.4.0-rc1
version using therelease
task:```sh # In the release-tools project: bundle exec rake "release[10.4.0-rc1]" ```
-
Check progress of EE packages build and CE packages build -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.4.0-rc1
to staging.gitlab.comsh # In the takeoff project: bin/takeoff-deploy -e staging -v 10.4.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. -
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.4.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.4.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 -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.4.0-rc1
to canary.gitlab.comsh # In the takeoff project: bin/takeoff-deploy -e canary -v 10.4.0-rc1.ee.0"
-
Announce on the #releases
Slack channels:10.4.0-rc1
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. 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.4.0-rc1. For status updates, please follow https://twitter.com/GitLabStatus"
* With downtime: 1 hour before!tweet "We will be deploying GitLab EE 10.4.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.4.0-rc1 starting at X:Y UTC"
-
On video call, deploy release 10.4.0-rc1
to GitLab.com# In the takeoff project: bin/takeoff-deploy -e production -v 10.4.0-rc1.ee.0"
-
Tweet in the #production
channel that the deployment has finished:!tweet "GitLab EE 10.4.0-rc1 has been deployed."
-
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 -
Post a tweet about the 10.4.0-rc1
release in the#releases
channel:!tweet "GitLab 10.4.0-rc1 is available: https://packages.gitlab.com/gitlab/unstable This is a release candidate, we'll release 10.4 on the 22nd of this month."
-
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:
- After feature freeze only regression and security fixes can be
cherry-picked into
10-4-stable
. - 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. -
Cherry-pick changes into preparation MRs following their instructions -
Cherry-pick remaining merge requests labeled ~"Pick into 10.4" using this Merged MRs list -
Check the following list of critical issues/MRs which are to be included in
10.4.0
. Ensure each has made both CE and EE -
Follow the Creating subsequent RCs guide for
10.4.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-4-stable
into EE10-4-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.4.0-rc1-ee..10-4-stable-ee -- db/migrate db/post_migrate
=> -
In #releases
: I'm going to tag10.4.0-rc2
-
Tag the 10.4.0-rc2
version using therelease
task:```sh # In the release-tools project: bundle exec rake "release[10.4.0-rc2]" ```
-
-
Check progress of EE packages build and CE packages build -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.4.0-rc2
to staging.gitlab.com# In the takeoff project: bin/takeoff-deploy -e staging -v 10.4.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.4.0-rc2
has been deployed to staging. Blog post draft: MERGE_REQUEST_URL -
Announce with an @product-team
mention on the#product
Slack channel: @product-team10.4.0-rc2
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 -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.4.0-rc2
to canary.gitlab.com# In the takeoff project: bin/takeoff-deploy -e canary -v 10.4.0-rc2.ee.0"
-
Announce on the #releases
Slack channels:10.4.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. 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.4.0-rc2. For status updates, please follow https://twitter.com/GitLabStatus"
- With downtime: 1 hour before
!tweet "We will be deploying GitLab EE 10.4.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.4.0-rc2 starting at X:Y UTC"
-
On video call, deploy release 10.4.0-rc2
to GitLab.com# In the takeoff project: bin/takeoff-deploy -e production -v 10.4.0-rc2.ee.0"
-
Tweet in the #production
channel that the deployment has finished:!tweet "GitLab EE 10.4.0-rc2 has been deployed."
-
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 -
Post a tweet about the 10.4.0-rc2
release in the#releases
channel:!tweet "GitLab 10.4.0-rc2 is available: https://packages.gitlab.com/gitlab/unstable This is a release candidate, we'll release 10.4 on the 22nd of this month."
RC3
-
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.4" using this Merged MRs list -
Check the following list of critical issues/MRs which are to be included in
10.4.0
. Ensure each has made both CE and EE-
REFERENCE_TO_MR_TO_PICK
-
-
Follow the Creating subsequent RCs guide for
10.4.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-4-stable
into EE10-4-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.4.0-rc1-ee..10-4-stable-ee -- db/migrate db/post_migrate
=> https://gitlab.com/gitlab-org/gitlab-ce/snippets/1692709 -
In #releases
: I'm going to tag10.4.0-rc3
-
Tag the 10.4.0-rc3
version using therelease
task:```sh # In the release-tools project: bundle exec rake "release[10.4.0-rc3]" ```
-
-
Check progress of EE packages build and CE packages build -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.4.0-rc3
to staging.gitlab.com# In the takeoff project: bin/takeoff-deploy -e staging -v 10.4.0-rc3.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. First batch output: https://gitlab.com/gitlab-org/gitlab-ce/snippets/1692736 Post-deployment output: https://gitlab.com/gitlab-org/gitlab-ce/snippets/1692748 -
Announce on the #releases
Slack channels:10.4.0-rc3
has been deployed to staging. Blog post draft: MERGE_REQUEST_URL -
Announce with an @product-team
mention on the#product
Slack channel: @product-team10.4.0-rc3
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 -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.4.0-rc3
to canary.gitlab.com# In the takeoff project: bin/takeoff-deploy -e canary -v 10.4.0-rc3.ee.0"
-
Announce on the #releases
Slack channels:10.4.0-rc3
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. 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.4.0-rc3. For status updates, please follow https://twitter.com/GitLabStatus"
- With downtime: 1 hour before
!tweet "We will be deploying GitLab EE 10.4.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.4.0-rc3 starting at X:Y UTC"
-
On video call, deploy release 10.4.0-rc3
to GitLab.com# In the takeoff project: bin/takeoff-deploy -e production -v 10.4.0-rc3.ee.0"
-
Tweet in the #production
channel that the deployment has finished:!tweet "GitLab EE 10.4.0-rc3 has been deployed."
-
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 -
Post a tweet about the 10.4.0-rc3
release in the#releases
channel:!tweet "GitLab 10.4.0-rc3 is available: https://packages.gitlab.com/gitlab/unstable This is a release candidate, we'll release 10.4 on the 22nd of this month."
RC4
-
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.4" using this Merged MRs list -
Check the following list of critical issues/MRs which are to be included in
10.4.0
. Ensure each has made both CE and EE-
REFERENCE_TO_MR_TO_PICK
-
-
Follow the Creating subsequent RCs guide for
10.4.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-4-stable
into EE10-4-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.4.0-rc4-ee..10-4-stable-ee -- db/migrate db/post_migrate
=> https://gitlab.com/snippets/1692908 -
In #releases
: I'm going to tag10.4.0-rc4
-
Tag the 10.4.0-rc4
version using therelease
task:```sh # In the release-tools project: bundle exec rake "release[10.4.0-rc4]" ```
-
-
Check progress of EE packages build and CE packages build -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.4.0-rc4
to staging.gitlab.com# In the takeoff project: bin/takeoff-deploy -e staging -v 10.4.0-rc4.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.4.0-rc4
has been deployed to staging. Blog post draft: MERGE_REQUEST_URL -
Announce with an @product-team
mention on the#product
Slack channel: @product-team10.4.0-rc4
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 -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.4.0-rc4
to canary.gitlab.com# In the takeoff project: bin/takeoff-deploy -e canary -v 10.4.0-rc4.ee.0"
-
Announce on the #releases
Slack channels:10.4.0-rc4
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. 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.4.0-rc4. For status updates, please follow https://twitter.com/GitLabStatus"
- With downtime: 1 hour before
!tweet "We will be deploying GitLab EE 10.4.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.4.0-rc4 starting at X:Y UTC"
-
On video call, deploy release 10.4.0-rc4
to GitLab.com# In the takeoff project: bin/takeoff-deploy -e production -v 10.4.0-rc4.ee.0"
-
Tweet in the #production
channel that the deployment has finished:!tweet "GitLab EE 10.4.0-rc4 has been deployed."
-
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 -
Post a tweet about the 10.4.0-rc4
release in the#releases
channel:!tweet "GitLab 10.4.0-rc4 is available: https://packages.gitlab.com/gitlab/unstable This is a release candidate, we'll release 10.4 on the 22nd of this month."
RC6
-
Create preparation MRs by following the instructions in release-tools.
New MRs:
-
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16508
-
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4114/
-
Cherry-pick changes into preparation MRs following their instructions -
Cherry-pick remaining merge requests labeled ~"Pick into 10.4" using this Merged MRs list -
Check the following list of critical issues/MRs which are to be included in
10.4.0
. Ensure each has made both CE and EE-
REFERENCE_TO_MR_TO_PICK
-
-
Follow the Creating subsequent RCs guide for
10.4.0-rc6
:-
If you didn't merge CE into EE in the preparation branches, or if the CE stable branch had additional commits, merge CE 10-4-stable
into EE10-4-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.4.0-rc5-ee..10-4-stable-ee -- db/migrate db/post_migrate
=> -
In #releases
: I'm going to tag10.4.0-rc6
-
Tag the 10.4.0-rc6
version using therelease
task:```sh # In the release-tools project: bundle exec rake "release[10.4.0-rc6]" ```
-
-
Check progress of EE packages build and CE packages build -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.4.0-rc6
to staging.gitlab.com# In the takeoff project: bin/takeoff-deploy -e staging -v 10.4.0-rc6.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.4.0-rc6
has been deployed to staging. Blog post draft: MERGE_REQUEST_URL -
Announce with an @product-team
mention on the#product
Slack channel: @product-team10.4.0-rc6
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 -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.4.0-rc6
to canary.gitlab.com# In the takeoff project: bin/takeoff-deploy -e canary -v 10.4.0-rc6.ee.0"
-
Announce on the #releases
Slack channels:10.4.0-rc6
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. 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.4.0-rc6. For status updates, please follow https://twitter.com/GitLabStatus"
- With downtime: 1 hour before
!tweet "We will be deploying GitLab EE 10.4.0-rc6 starting at X:Y UTC, 15 mins of downtime expected"
- Without downtime: 15 minutes before
!tweet "We are about to deploy GitLab EE 10.4.0-rc6 starting at X:Y UTC"
-
On video call, deploy release 10.4.0-rc6
to GitLab.com# In the takeoff project: bin/takeoff-deploy -e production -v 10.4.0-rc6.ee.0"
-
Tweet in the #production
channel that the deployment has finished:!tweet "GitLab EE 10.4.0-rc6 has been deployed."
-
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 -
Post a tweet about the 10.4.0-rc6
release in the#releases
channel:!tweet "GitLab 10.4.0-rc6 is available: https://packages.gitlab.com/gitlab/unstable This is a release candidate, we'll release 10.4 on the 22nd of this month."
RC7
-
Create preparation MRs by following the instructions in release-tools. -
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16519
-
Cherry-pick changes into preparation MRs following their instructions -
Cherry-pick remaining merge requests labeled ~"Pick into 10.4" using this Merged MRs list -
Check the following list of critical issues/MRs which are to be included in
10.4.0
. Ensure each has made both CE and EE-
REFERENCE_TO_MR_TO_PICK
-
-
Follow the Creating subsequent RCs guide for
10.4.0-rc7
:-
If you didn't merge CE into EE in the preparation branches, or if the CE stable branch had additional commits, merge CE 10-4-stable
into EE10-4-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.4.0-rc1-ee..10-4-stable-ee -- db/migrate db/post_migrate
=> -
In #releases
: I'm going to tag10.4.0-rc7
-
Tag the 10.4.0-rc7
version using therelease
task:```sh # In the release-tools project: bundle exec rake "release[10.4.0-rc7]" ```
-
-
Check progress of EE packages build and CE packages build -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.4.0-rc7
to staging.gitlab.com# In the takeoff project: bin/takeoff-deploy -e staging -v 10.4.0-rc7.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.4.0-rc7
has been deployed to staging. Blog post draft: MERGE_REQUEST_URL -
Announce with an @product-team
mention on the#product
Slack channel: @product-team10.4.0-rc7
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 -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.4.0-rc7
to canary.gitlab.com# In the takeoff project: bin/takeoff-deploy -e canary -v 10.4.0-rc7.ee.0"
-
Announce on the #releases
Slack channels:10.4.0-rc7
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. 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.4.0-rc7. For status updates, please follow https://twitter.com/GitLabStatus"
- With downtime: 1 hour before
!tweet "We will be deploying GitLab EE 10.4.0-rc7 starting at X:Y UTC, 15 mins of downtime expected"
- Without downtime: 15 minutes before
!tweet "We are about to deploy GitLab EE 10.4.0-rc7 starting at X:Y UTC"
-
On video call, deploy release 10.4.0-rc7
to GitLab.com# In the takeoff project: bin/takeoff-deploy -e production -v 10.4.0-rc7.ee.0"
-
Tweet in the #production
channel that the deployment has finished:!tweet "GitLab EE 10.4.0-rc7 has been deployed."
-
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 -
Post a tweet about the 10.4.0-rc7
release in the#releases
channel:!tweet "GitLab 10.4.0-rc7 is available: https://packages.gitlab.com/gitlab/unstable This is a release candidate, we'll release 10.4 on the 22nd of this month."
RC8
-
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.4" using this Merged MRs list -
Check the following list of critical issues/MRs which are to be included in
10.4.0
. Ensure each has made both CE and EE-
REFERENCE_TO_MR_TO_PICK
-
-
Follow the Creating subsequent RCs guide for
10.4.0-rc8
:-
If you didn't merge CE into EE in the preparation branches, or if the CE stable branch had additional commits, merge CE 10-4-stable
into EE10-4-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.4.0-rc7-ee..10-4-stable-ee -- db/migrate db/post_migrate
=> -
In #releases
: I'm going to tag10.4.0-rc8
-
Tag the 10.4.0-rc8
version using therelease
task:```sh # In the release-tools project: bundle exec rake "release[10.4.0-rc8]" ```
-
-
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.4.0-rc8
to staging.gitlab.com# In the takeoff project: bin/takeoff-deploy -e staging -v 10.4.0-rc8.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.4.0-rc8
has been deployed to staging. Blog post draft: MERGE_REQUEST_URL -
Announce with an @product-team
mention on the#product
Slack channel: @product-team10.4.0-rc8
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 -
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.4.0-rc8
to canary.gitlab.com# In the takeoff project: bin/takeoff-deploy -e canary -v 10.4.0-rc8.ee.0"
-
Announce on the #releases
Slack channels:10.4.0-rc8
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.4.0-rc8. For status updates, please follow https://twitter.com/GitLabStatus"
- With downtime: 1 hour before
!tweet "We will be deploying GitLab EE 10.4.0-rc8 starting at X:Y UTC, 15 mins of downtime expected"
- Without downtime: 15 minutes before
!tweet "We are about to deploy GitLab EE 10.4.0-rc8 starting at X:Y UTC"
-
On video call, deploy release 10.4.0-rc8
to GitLab.com# In the takeoff project: bin/takeoff-deploy -e production -v 10.4.0-rc8.ee.0"
-
Tweet in the #production
channel that the deployment has finished:!tweet "GitLab EE 10.4.0-rc8 has been deployed."
-
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 -
Post a tweet about the 10.4.0-rc8
release in the#releases
channel:!tweet "GitLab 10.4.0-rc8 is available: https://packages.gitlab.com/gitlab/unstable This is a release candidate, we'll release 10.4 on the 22nd of this month."
#### 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.4" using this [Merged MRs list]
- Check the following list of critical issues/MRs which are to be included in `10.4.0`. Ensure each has made both CE and EE
- [ ] REFERENCE_TO_MR_TO_PICK
- Follow the [Creating subsequent RCs] guide for `10.4.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-4-stable` into EE `10-4-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.4.0-rc1-ee..10-4-stable-ee -- db/migrate db/post_migrate` =>
- [ ] In `#releases`: I'm going to tag `10.4.0-rc2`
- [ ] Tag the `10.4.0-rc2` version using the [`release` task]:
```sh
# In the release-tools project:
bundle exec rake "release[10.4.0-rc2]"
```
- [ ] Check progress of [EE packages build](https://dev.gitlab.org/gitlab/omnibus-gitlab/commits/10.4.0+rc2.ee.0) and [CE packages build](https://dev.gitlab.org/gitlab/omnibus-gitlab/commits/10.4.0+rc2.ce.0)
- [ ] 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.4.0-rc2`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_10.4.0-rc2.ee.0_amd64.deb) to [staging.gitlab.com]
```sh
# In the takeoff project:
bin/takeoff-deploy -e staging -v 10.4.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.4.0-rc2` has been deployed to staging. Blog post draft: MERGE_REQUEST_URL
- [ ] Announce with an `@product-team` mention on the `#product` Slack channel: @product-team `10.4.0-rc2` has been deployed to staging. Blog post draft: MERGE_REQUEST_URL
- [ ] Wait for confirmation from [`@bjgopinath`](https://gitlab.com/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.4.0-rc2`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_10.4.0-rc2.ee.0_amd64.deb) to [canary.gitlab.com]
```sh
# In the takeoff project:
bin/takeoff-deploy -e canary -v 10.4.0-rc2.ee.0"
```
- [ ] Announce on the `#releases` Slack channels: `10.4.0-rc2` has been deployed to canary. Blog post draft: MERGE_REQUEST_URL
- [ ] Wait for confirmation from [`@bjgopinath`](https://gitlab.com/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.4.0-rc2.
For status updates, please follow https://twitter.com/GitLabStatus"
```
* With downtime: 1 hour before
```
!tweet "We will be deploying GitLab EE 10.4.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.4.0-rc2 starting at X:Y UTC"
```
- [ ] On video call, [deploy] release [`10.4.0-rc2`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_10.4.0-rc2.ee.0_amd64.deb) to GitLab.com
```sh
# In the takeoff project:
bin/takeoff-deploy -e production -v 10.4.0-rc2.ee.0"
```
- [ ] Tweet in the `#production` channel that the deployment has finished:
```
!tweet "GitLab EE 10.4.0-rc2 has been deployed."
```
- [ ] 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.4.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.4.0-rc2` release in the `#releases` channel:
```
!tweet "GitLab 10.4.0-rc2 is available: https://packages.gitlab.com/gitlab/unstable
This is a release candidate, we'll release 10.4 on the 22nd of this month."
```
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.4.0-rc21]"
-
Check progress of [EE packages build] and [CE packages build] -
In #production
: I'm going to deploy10.4.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.4.0-rc21
to staging.gitlab.com# In the takeoff project: bin/takeoff-deploy -e staging -v 10.4.0-rc21.ee.0"
-
Announce on the #releases
Slack channels:10.4.0-rc21
has been deployed to staging. Blog post draft: MERGE_REQUEST_URL -
Announce with an @product-team
mention on the#product
Slack channel: @product-team10.4.0-rc21
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 -
In #production
: I'm going to deploy10.4.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.4.0-rc21
to canary.gitlab.com# In the takeoff project: bin/takeoff-deploy -e canary -v 10.4.0-rc21.ee.0"
-
Announce on the #releases
Slack channels:10.4.0-rc21
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 -
In #production
: I'm going to deploy10.4.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.4.0-rc2. For status updates, please follow https://twitter.com/GitLabStatus"
- With downtime: 1 hour before
!tweet "We will be deploying GitLab EE 10.4.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.4.0-rc2 starting at X:Y UTC"
-
On video call, deploy release 10.4.0-rc21
to GitLab.com# In the takeoff project: bin/takeoff-deploy -e production -v 10.4.0-rc21.ee.0"
-
Tweet in the #production
channel that the deployment has finished:!tweet "GitLab EE 10.4.0-rc21 has been deployed."
-
Verify that packages appear on packages.gitlab.com
: EE & CE -
Post a tweet about the 10.4.0-rc21
release in the#releases
channel:!tweet "GitLab 10.4.0-rc21 is available: https://packages.gitlab.com/gitlab/unstable This is a release candidate, we'll release 10.4 on the 22nd of this month."
-
- Final RC is ready for tagging. Including changes at this stage requires signoff from VP of Eng.
-
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 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.) -
If at this time final release is not ready for tagging, notify the CTO
-
-
Before 10:00 UTC:
-
In #releases
: I'm going to tag10.4.0
-
Tag the 10.4.0
version using therelease
task:```sh # In the release-tools project: bundle exec rake "release[10.4.0]" ```
-
Check progress of [EE packages build] and [CE packages build]
-
-
Before 12:00 UTC:
-
In #production
: I'm going to deploy10.4.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.4.0
to staging.gitlab.com```sh # In the takeoff project: bin/takeoff-deploy -e staging -v 10.4.0-ee.0" ```
-
Announce on the #releases
Slack channels:10.4.0
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 -
In #production
: I'm going to deploy10.4.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.4.0
to canary.gitlab.com```sh # In the takeoff project: bin/takeoff-deploy -e canary -v 10.4.0-ee.0" ```
-
Announce on the #releases
Slack channels:10.4.0
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 -
In #production
: I'm going to deploy10.4.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.4.0. For status updates, please follow https://twitter.com/GitLabStatus"
* With downtime: 1 hour before!tweet "We will be deploying GitLab EE 10.4.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.4.0 starting at X:Y UTC"
-
On video call, deploy release 10.4.0
to GitLab.com```sh # In the takeoff project: bin/takeoff-deploy -e production -v 10.4.0-ee.0" ```
-
Tweet in the #production
channel that the deployment has finished:!tweet "GitLab EE 10.4.0 has been deployed."
-
Create the first patch issue using the patch_issue
task:```sh # In the release-tools project: bundle exec rake "patch_issue[10.4.1]" ```
-
If at this point final release is not ready for public, notify the CEO
-
-
At 15:00 UTC:
- Make sure that neither packages nor blog post get published before that time without approval by the marketing team.
-
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.4.0
version on https://version.gitlab.com -
Ensure someone tweets about the 10.4.0
release in the#releases
channel