From 98e83e475ee084d8467938ad93381b0c1e443730 Mon Sep 17 00:00:00 2001 From: Nathan Friend Date: Tue, 21 Apr 2020 15:02:05 -0400 Subject: [PATCH] Clarify auto-deploy schedule --- general/deploy/auto-deploy.md | 74 ++++++++++++++++++++++++++--------- 1 file changed, 55 insertions(+), 19 deletions(-) diff --git a/general/deploy/auto-deploy.md b/general/deploy/auto-deploy.md index 35dcac15..3d4c98c2 100644 --- a/general/deploy/auto-deploy.md +++ b/general/deploy/auto-deploy.md @@ -104,7 +104,7 @@ non-production environment. ### Auto-deploy schedule Using an example of a non existent release **11.12**, let's assume that a -milestone is created with a start date of the 23rd and a due date of the 22nd. +milestone is created with a start date of 2019/06/23 and a due date of 2019/07/22. The table below gives an overview of the schedule: @@ -117,44 +117,46 @@ The table below gives an overview of the schedule: - 23rd + 2019/06/23 * The **11.12** milestone is active. - * An automated CI job creates a branch named **11-12-auto-deploy-20190702** in gitlab-foss, omnibus-gitlab and + * An automated CI job creates a branch named **11-12-auto-deploy-20190623** in gitlab-foss, omnibus-gitlab and gitlab from the **master** branch. * The latest green commit of gitlab is used to update versions of GitLab services in the omnibus-gitlab repository. - * The commits in gitlab and omnibus-gitlab are tagged with **11.12.201907021014+aaaa.ffff**. * The resulting auto-deploy package is deployed to staging and then production canary - 23rd..1st + 2019/06/23..2019/07/01 - * In case an issue is discovered after deployment, one or many MRs need to be created resolving the issue. - * MRs are reviewed and merged to the `master` branch using the regular process. - * In order for the MR to be included in auto-deploy branch, a label **Pick into auto-deploy** needs to be applied. See [here](https://about.gitlab.com/handbook/engineering/releases/#gitlabcom-releases-2) for up-to-date information on how to ensure your MR is picked. + * In case an issue is discovered after deployment, one or many MRs need to be + created resolving the issue. In order for the MR to be included in + auto-deploy branch, a **Pick into auto-deploy** label needs to be applied to the MR. + See [here](https://about.gitlab.com/handbook/engineering/releases/#gitlabcom-releases-2) + for up-to-date information on how to ensure your MR is picked. + * Only MRs with a + [**S1** or **S2** severity label](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#severity) + are eligible to be picked into the auto-deploy branch. * A CI job checks the MRs for auto-deploy - * Labeled MRs are picked automatically into the **11-12-auto-deploy-20190723** branch + * Labeled MRs are picked automatically into the **11-12-auto-deploy-20190623** branch * The merge train ensures that CE is merged into EE * MRs are updated with a comment to let the MR author know that the change has been prepped for next deployment. - * The next green commit on the auto-deploy branch is tagged with **11.12.201907021014+bbbb.ffff** - * The resulting auto-deploy package is deployed to staging, and then - production canary + * The resulting auto-deploy package is deployed to staging, and then production canary * In case the latest green commit has already been deployed, no action is taken. * This process is repeated on a frequent interval, with multiple deployments to the staging and production canary environments - * Other MRs (ones without the label) merged to the `master` branch are not included until the next week's + * Other MRs (ones without the **Pick into auto-deploy** label) merged to the `master` branch are not included until the next week's auto-deploy branch, **11-12-auto-deploy-20190701** - 1st + 2019/07/01 * Branch **11-12-auto-deploy-20190701** created in gitlab-foss, omnibus-gitlab and @@ -165,7 +167,7 @@ The table below gives an overview of the schedule: - 8th + 2019/07/08 * Branch **11-12-auto-deploy-20190708** created in gitlab-foss, omnibus-gitlab and @@ -176,7 +178,7 @@ The table below gives an overview of the schedule: - 15th + 2019/07/15 * Branch **11-12-auto-deploy-20190715** created in gitlab-foss, omnibus-gitlab and @@ -187,7 +189,18 @@ The table below gives an overview of the schedule: - 22nd RELEASE DAY + 2019/07/18 **or** the Friday before, if 2019/07/18 falls on a weekend + + + * Branch **11-12-auto-deploy-20190718** created in gitlab-foss, omnibus-gitlab and + gitlab from **master** + * The same picking and deploying process is now done for the new auto-deploy + branch, **11-12-auto-deploy-20190718** + + + + + 2019/07/22: RELEASE DAY * The commit that is currently deployed to production will be used for the official @@ -203,10 +216,10 @@ The table below gives an overview of the schedule: - 23rd + 2019/07/23 - * A new milestone, **11.13** is active with a start date of the 23rd and a due date of the 22nd + * A new milestone, **11.13** is active with a start date of 2019/07/23 and a due date of 2019/08/22 * The process auto-deploy cycle repeats @@ -257,6 +270,29 @@ If you do not have access to ChatOps, see [how you can obtain access](https://do ## FAQ +### When does a merge request need to be merged in order to be included in the monthly self-managed release on the 22nd? + +If the 18th is a weekday, by the end of the day on the 17th. + +If the 18th is a weekend, by the end of the day on Thursday. + +### Is this guaranteed? + +**No.** There are a few reasons a commit merged before the cutoff above may +_not_ be included in the monthly release: + +1. If the latest auto-deploy branch (`11-12-auto-deploy-20190718` in the example + above) contains a major regression, this release candidate will be rejected + and the latest stable GitLab.com deployment will be used instead. +1. If the pipeline failed for the commit and no future commit has fixed the + pipeline + 1. This is because the CI job selects the latest **green** commit when + deciding where to cut the new auto-deploy branch + +To increase the likehood that an MR will be included in the release, aim to have +the MR merged before the creation of the _previous_ auto-deploy branch, i.e. by +the end of the day on the 14th. + ### How does this change the existing feature freeze on the 7th? Throughout the growth of GitLab as a company, the feature freeze implied -- GitLab