Merge branch 'master' into update-todo-in-uiupdate-todo-in-ui

* master: (435 commits)
  Change occurrence of Sidekiq::Testing.inline!
  Fix order-dependent spec failure in appearance_spec.rb
  Put a failed example from appearance_spec in quarantine
  Cache PerformanceBar.allowed_user_ids list locally and in Redis
  Add Grafana to Admin > Monitoring menu when enabled
  Add changelog entry
  Add salesforce logo
  Move error_tracking_frontend specs to Jest
  Only save Peek session in Redis when Peek is enabled
  Migrate markdown header_spec.js to Jest
  Fix golint command in Go guide doc to be recursive
  Move images to their own dirs
  Gitlab -> GitLab
  Re-align CE and EE API docs
  Rename Release groups in issue_workflow.md
  Update api docs to finish aligning EE and CE docs
  Update locale.pot
  Update TODO: allow_collaboration column renaming
  Show upcoming status for releases
  Rebased and squashed commits
  ...

2 files changed, 39 insertions, 23 deletions

diff --git a/doc/topics/application_development_platform/index.md b/doc/topics/application_development_platform/index.md
index e8960a76dd9..8742606479d 100644
--- a/doc/topics/application_development_platform/index.md
+++ b/doc/topics/application_development_platform/index.md
@@ -1,12 +1,21 @@
 # Application Development Platform
 
-The GitLab Application Development Platform refers to the set of GitLab features that can be used by operations teams to 
-provide a full development environment to internal software development teams.
+The GitLab Application Development Platform refers to the set of GitLab features used to create, configure, and manage
+a complete software development environment. It provides development, operations, and security teams with a robust feature set aimed at supporting best practices out of the box.
 
 ## Overview
 
-The GitLab Application Development Platform aims to reduce and even eliminate the time it takes for an Operations team
-to provide a full environment for software developers. It comprises the following high-level elements:
+The GitLab Application Development Platform aims to:
+
+- Reduce and even eliminate the time it takes for an Operations team
+  to provide a full environment for software developers.
+- Get developers up and running fast so they can focus on writing 
+  great applications with a robust development feature set.
+- Provide best-of-breed security features so that applications developed 
+  with GitLab are not affected by vulnerabilities that may lead to security 
+  problems and unintended use.
+
+It is comprised of the following high-level elements:
 
 1. Compute
 1. Build, test, and deploy a wide range of applications
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index 702245b22a0..bd788cb138c 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -175,8 +175,8 @@ When using Auto DevOps, you may want to deploy different environments to
 different Kubernetes clusters. This is possible due to the 1:1 connection that
 [exists between them](../../user/project/clusters/index.md#multiple-kubernetes-clusters-premium).
 
-In the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
-(used behind the scenes by Auto DevOps), there are currently 3 defined environment names that you need to know:
+In the [Auto DevOps template] (used behind the scenes by Auto DevOps), there
+are currently 3 defined environment names that you need to know:
 
 - `review/` (every environment starting with `review/`)
 - `staging`
@@ -662,25 +662,32 @@ to the desired environment. See [Limiting environment scopes of variables](../..
 
 ### Customizing `.gitlab-ci.yml`
 
-If you want to modify the CI/CD pipeline used by Auto DevOps, you can copy the
-[Auto DevOps template] into your project's repo and edit as you see fit.
+Everything about Auto DevOps is customizable since the [Auto DevOps template]
+is just an example of a [`.gitlab-ci.yml`](../../ci/yaml/README.md) and uses
+only features that are available to any `.gitlab-ci.yml`.
 
-Assuming that your project is new or it doesn't have a `.gitlab-ci.yml` file
-present:
+Auto DevOps is completely customizable because the [Auto DevOps template]:
 
-1. From your project home page, either click on the "Set up CI/CD" button, or click
-   on the plus button and (`+`), then "New file"
-1. Pick `.gitlab-ci.yml` as the template type
-1. Select "Auto-DevOps" from the template dropdown
-1. Edit the template or add any jobs needed
-1. Give an appropriate commit message and hit "Commit changes"
+- Is just an implementation of a [`.gitlab-ci.yml`](../../ci/yaml/README.md) file.
+- Uses only features available to any implementation of `.gitlab-ci.yml`.
 
-TIP: **Tip:** The Auto DevOps template includes useful comments to help you
-customize it. For example, if you want deployments to go to a staging environment
-instead of directly to a production one, you can enable the `staging` job by
-renaming `.staging` to `staging`. Then make sure to uncomment the `when` key of
-the `production` job to turn it into a manual action instead of deploying
-automatically.
+If you want to modify the CI/CD pipeline used by Auto DevOps, you can [`include`
+the template](../../ci/yaml/README.md#includetemplate) and customize as
+needed. To do this, add a `.gitlab-ci.yml` file to the root of your repository
+containing the following:
+
+```yml
+include:
+  - template: Auto-DevOps.gitlab-ci.yml
+```
+
+Then add any extra changes you want. Your additions will be merged with the
+[Auto DevOps template] using the behaviour described for
+[`include`](../../ci/yaml/README.md#include).
+
+It is also possible to copy and paste the contents of the [Auto DevOps
+template] into your project and edit this as needed. You may prefer to do it
+that way if you want to specifically remove any part of it.
 
 ### Using components of Auto-DevOps
 
@@ -723,7 +730,7 @@ also be customized, and you can easily use a [custom buildpack](#custom-buildpac
 | `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | From Gitlab 11.11, this variable can be used to set a username to connect to the helm repository. Defaults to no credentials. (Also set AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD) |
 | `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | From Gitlab 11.11, this variable can be used to set a password to connect to the helm repository. Defaults to no credentials. (Also set AUTO_DEVOPS_CHART_REPOSITORY_USERNAME) |
 | `REPLICAS`                   | The number of replicas to deploy; defaults to 1.                                                                                                                                                                              |
-| `PRODUCTION_REPLICAS`        | The number of replicas to deploy in the production environment. This takes precedence over `REPLICAS`; defaults to 1.                                                                                                         |
+| `PRODUCTION_REPLICAS`        | The number of replicas to deploy in the production environment. Takes precedence over `REPLICAS` and defaults to 1. For zero downtime upgrades, set to 2 or greater.                                |
 | `CANARY_REPLICAS`            | The number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md); defaults to 1                                                                              |
 | `CANARY_PRODUCTION_REPLICAS` | The number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md) in the production environment. This takes precedence over `CANARY_REPLICAS`; defaults to 1  |
 | `ADDITIONAL_HOSTS`           | Fully qualified domain names specified as a comma-separated list that are added to the ingress hosts.                                                                                                                         |