diff --git a/general/deploy/auto-deploy.md b/general/deploy/auto-deploy.md
index 35dcac1505494d750314f868710f79161fcac5ed..3d4c98c2089b44214cbbd8c70f7b898d47d98b1d 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