Add latest changes from gitlab-org/gitlab@master

1 files changed, 177 insertions, 245 deletions

diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index beb5f6a58f6..f4936e9162d 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -6,320 +6,269 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Auto DevOps **(FREE)**
 
-> - Introduced in GitLab 11.0 for general availability.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38366) in GitLab 11.0.
 
-GitLab Auto DevOps helps to reduce the complexity of software delivery by
-setting up pipelines and integrations for you. Auto DevOps configures
-GitLab CI/CD pipelines including security auditing and vulnerability
-testing.
+GitLab Auto DevOps is a collection of pre-configured features and integrations
+that work together to support your software delivery process.
 
-Using Auto DevOps, you can:
+Auto DevOps features and integrations:
 
-- Detect the language of your code.
-- Automatically build, test, and measure code quality.
-- Scan for potential vulnerabilities, security flaws, and licensing issues.
-- Monitor in real-time.
+- Detect your code's language.
+- Build and test your application.
+- Measure code quality.
+- Scan for vulnerabilities and security flaws.
+- Check for licensing issues.
+- Monitor in real time.
 - Deploy your application.
 
-The functionality of Auto DevOps is based on default CI/CD templates that
-auto-discover your source code. These templates enable GitLab to provide
-consistency across your projects, seamless management of processes, and faster
-creation of new projects. Leveraging [CI/CD best practices](../../ci/pipelines/pipeline_efficiency.md)
-and tools, Auto DevOps lets you push your code, with GitLab doing the rest,
-improving your productivity and efficiency.
-
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For an introduction to Auto DevOps, watch [AutoDevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4) or see this [overview](https://about.gitlab.com/stages-devops-lifecycle/auto-devops/).
+For an introduction to Auto DevOps, watch [Auto DevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4).
 
-For requirements, read [Requirements for Auto DevOps](requirements.md) for more information.
+## Auto DevOps features
 
-For GitLab contributors, see the [Auto DevOps development guide](../../development/auto_devops.md).
+Based on the DevOps [stages](stages.md), use Auto DevOps to:
 
-## Enable or disable Auto DevOps
+**Build your app:**
 
-Auto DevOps is enabled by default for all projects in self-managed instances
-(as of [GitLab 11.3](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729)),
-but not for GitLab SaaS instances.
+- [Auto Build](stages.md#auto-build)
+- [Auto Dependency Scanning](stages.md#auto-dependency-scanning)
 
-When first using Auto DevOps, review the [requirements](requirements.md) to
-ensure all the necessary components to make full use of Auto DevOps are
-available. First-time users should follow the [quick start guide](quick_start_guide.md).
+**Test your app:**
 
-Depending on your instance type, you can enable or disable Auto DevOps at the
-following levels:
+- [Auto Test](stages.md#auto-test)
+- [Auto Browser Performance Testing](stages.md#auto-browser-performance-testing)
+- [Auto Code Intelligence](stages.md#auto-code-intelligence)
+- [Auto Code Quality](stages.md#auto-code-quality)
+- [Auto Container Scanning](stages.md#auto-container-scanning)
+- [Auto License Compliance](stages.md#auto-license-compliance)
 
-| Instance type       | [Project](#at-the-project-level) | [Group](#at-the-group-level) | [Instance](#at-the-instance-level) (Admin Area)  |
-|---------------------|------------------------|------------------------|------------------------|
-| GitLab SaaS         | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No |
-| GitLab self-managed | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes |
+**Deploy your app:**
 
-When you enable Auto DevOps for your instance, it attempts to run on all
-pipelines in each project. The Auto DevOps setting automatically disables itself for individual
-projects on their first pipeline failure. An instance administrator can enable
-or disable this default in the [Auto DevOps settings](../../user/admin_area/settings/continuous_integration.md#auto-devops).
+- [Auto Review Apps](stages.md#auto-review-apps)
+- [Auto Deploy](stages.md#auto-deploy)
 
-[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26655) in GitLab 12.7,
-Auto DevOps runs on pipelines automatically only if a [`Dockerfile` or matching buildpack](stages.md#auto-build)
-exists.
+**Monitor your app:**
 
-If a [CI/CD configuration file](../../ci/yaml/index.md) is present in the
-project, it remains unchanged and Auto DevOps doesn't affect it.
+- [Auto Monitoring](stages.md#auto-monitoring)
 
-### At the project level
+**Secure your app:**
 
-When you enable Auto DevOps for a project, ensure that your project does not have a `.gitlab-ci.yml` present. If it exists, remove it before enabling Auto DevOps.
+- [Auto Dynamic Application Security Testing (DAST)](stages.md#auto-dast)
+- [Auto Static Application Security Testing (SAST)](stages.md#auto-sast)
+- [Auto Secret Detection](stages.md#auto-secret-detection)
 
-To enable it:
+### How it works
 
-1. Go to your project's **Settings > CI/CD > Auto DevOps**.
-1. Select the **Default to Auto DevOps pipeline** checkbox to enable it.
-1. (Optional, but recommended) When enabling, you can add in the
-   [base domain](#auto-devops-base-domain) Auto DevOps uses to
-   [deploy your application](stages.md#auto-deploy),
-   and choose the [deployment strategy](#deployment-strategy).
-1. Click **Save changes** for the changes to take effect.
+Auto DevOps detects your code language and uses [CI/CD templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates)
+to create and run default pipelines. All you need to kick it off is to
+[enable](#enable-or-disable-auto-devops) it.
 
-After enabling the feature, an Auto DevOps pipeline is triggered on the default branch.
+Auto DevOps starts by building and testing your application. Then, based on your
+[predefined deployment configuration](requirements.md),
+creates the necessary jobs to deploy your apps to staging
+and/or production. It also sets up [Review Apps](stages.md#auto-review-apps)
+so that you can preview your changes in a per-branch basis.
 
-### At the group level
+Note that you don't need to set up the deployment upfront. Auto DevOps
+still builds and tests your application. You can define the deployment later.
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52447) in GitLab 11.10.
+Auto DevOps avoids the hassle of having to create entire pipelines manually.
+Keep it simple and facilitate an iterative approach: ship your app first,
+then explore the [customizations](customize.md) later.
+You can also [manage Auto DevOps with APIs](customize.md#extend-auto-devops-with-the-api).
 
-Only administrators and group owners can enable or disable Auto DevOps at the group level.
+Some of the benefits of using Auto DevOps as part of your workflow are:
 
-When you enable Auto DevOps at group level, the subgroups and projects in that group inherit the configuration. Auto DevOps
-can be specifically enabled or disabled individually for projects and subgroups.
+- Consistency: always start from default templates.
+- Simplicity: create your pipeline with the default settings first, iterate later.
+- Productivity: deploy multiple apps in a short period of time.
+- Efficiency: get things done fast.
 
-To enable or disable Auto DevOps at the group level:
+### Comparison to application platforms and PaaS
 
-1. Go to your group's **Settings > CI/CD > Auto DevOps** page.
-1. Select the **Default to Auto DevOps pipeline** checkbox to enable it.
-1. Click **Save changes** for the changes to take effect.
+Auto DevOps provides features often included in an application
+platform or in a Platform as a Service (PaaS).
 
-### At the instance level **(FREE SELF)**
+Inspired by [Heroku](https://www.heroku.com/), Auto DevOps goes beyond it
+in multiple ways:
 
-Even when disabled at the instance level, group owners and project maintainers
-can still enable Auto DevOps at the group and project level, respectively.
+- Auto DevOps works with any Kubernetes cluster.
+- There is no additional cost.
+- You can use a cluster hosted by yourself or on any public cloud.
+- Auto DevOps offers an incremental graduation path. If you need to [customize](customize.md), start by changing the templates and evolve from there.
 
-1. As an administrator, on the top bar, select **Menu >** **{admin}** **Admin**.
-1. Go to **Settings > CI/CD > Continuous Integration and Deployment**.
-1. Select **Default to Auto DevOps pipeline for all projects** to enable it.
-1. (Optional) You can set up the Auto DevOps [base domain](#auto-devops-base-domain),
-   for Auto Deploy and Auto Review Apps to use.
-1. Click **Save changes** for the changes to take effect.
+## Get started with Auto DevOps
 
-### Deployment strategy
+To get started, you only need to [enable Auto DevOps](#enable-or-disable-auto-devops).
+This is enough to run an Auto DevOps pipeline to build and
+test your application.
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) in GitLab 11.0.
+If you want to build, test, and deploy your app:
 
-You can change the deployment strategy used by Auto DevOps by visiting your
-project's **Settings > CI/CD > Auto DevOps**. The following options
-are available:
+1. See the [requirements for deployment](requirements.md).
+1. [Enable Auto DevOps](#enable-or-disable-auto-devops).
+1. Follow the [quick start guide](#quick-start).
 
-- **Continuous deployment to production**: Enables [Auto Deploy](stages.md#auto-deploy)
-  with the default branch directly deployed to production.
-- **Continuous deployment to production using timed incremental rollout**: Sets the
-  [`INCREMENTAL_ROLLOUT_MODE`](customize.md#timed-incremental-rollout-to-production) variable
-  to `timed`. Production deployments execute with a 5 minute delay between
-  each increment in rollout.
-- **Automatic deployment to staging, manual deployment to production**: Sets the
-  [`STAGING_ENABLED`](customize.md#deploy-policy-for-staging-and-production-environments) and
-  [`INCREMENTAL_ROLLOUT_MODE`](customize.md#incremental-rollout-to-production) variables
-  to `1` and `manual`. This means:
+As Auto DevOps relies on many components, be familiar with:
 
-  - The default branch is directly deployed to staging.
-  - Manual actions are provided for incremental rollout to production.
+- [Continuous methodologies](../../ci/introduction/index.md)
+- [Docker](https://docs.docker.com)
+- [GitLab Runner](https://docs.gitlab.com/runner/)
 
-NOTE:
-Use the [blue-green deployment](../../ci/environments/incremental_rollouts.md#blue-green-deployment) technique
-to minimize downtime and risk.
+When deploying to a Kubernetes cluster make sure you're also familiar with:
 
-## Quick start
+- [Kubernetes](https://kubernetes.io/docs/home/)
+- [Helm](https://helm.sh/docs/)
+- [Prometheus](https://prometheus.io/docs/introduction/overview/)
 
-For GitLab.com users, see the [quick start guide](quick_start_guide.md)
-for setting up Auto DevOps deploying to a Kubernetes cluster on Google Kubernetes
-Engine (GKE).
+### Enable or disable Auto DevOps
 
-If you use a self-managed instance of GitLab, you must configure the
-[Google OAuth 2.0 OmniAuth Provider](../../integration/google.md) before
-configuring a cluster on GKE. After configuring the provider, you can follow
-the steps in the [quick start guide](quick_start_guide.md) to get started.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729) in GitLab 11.3, Auto DevOps is enabled by default.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26655) GitLab 12.7, Auto DevOps runs pipelines automatically only if a [`Dockerfile` or matching buildpack](stages.md#auto-build) exists.
 
-In [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) and later, it is
-possible to leverage Auto DevOps to deploy to [AWS ECS](requirements.md#auto-devops-requirements-for-amazon-ecs).
+Depending on your instance type, you can enable or disable Auto DevOps at the
+following levels:
 
-## Comparison to application platforms and PaaS
+| Instance type       | [Project](#at-the-project-level) | [Group](#at-the-group-level) | [Instance](#at-the-instance-level) (Admin Area)  |
+|---------------------|------------------------|------------------------|------------------------|
+| GitLab SaaS         | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No |
+| GitLab self-managed | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes |
 
-Auto DevOps provides features often included in an application
-platform or a Platform as a Service (PaaS). It takes inspiration from the
-innovative work done by [Heroku](https://www.heroku.com/) and goes beyond it
-in multiple ways:
+Before enabling Auto DevOps, consider [preparing it for deployment](requirements.md). If you don't, Auto DevOps can build and test your app,
+but cannot deploy it.
 
-- Auto DevOps works with any Kubernetes cluster; you're not limited to running
-  on infrastructure managed by GitLab. (Note that many features also work without Kubernetes).
-- There is no additional cost (no markup on the infrastructure costs), and you
-  can use a Kubernetes cluster you host or Containers as a Service on any
-  public cloud (for example, [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)).
-- Auto DevOps has more features including security testing, performance testing,
-  and code quality testing.
-- Auto DevOps offers an incremental graduation path. If you need advanced customizations,
-  you can start modifying the templates without starting over on a
-  completely different platform. Review the [customizing](customize.md) documentation for more information.
+#### At the project level
 
-## Features
+To use Auto DevOps for individual projects, you can enable it in a
+project-by-project basis. If you intend to use it for more projects,
+you can enable it for a [group](#at-the-group-level) or an
+[instance](#at-the-instance-level). This can save you the time of
+enabling it one by one.
 
-NOTE:
-Depending on your target platform, some features might not be available to you.
+Only project Maintainers can enable or disable Auto DevOps at the project level.
 
-Comprised of a set of [stages](stages.md), Auto DevOps brings these best practices to your
-project automatically:
+Before enabling Auto DevOps, ensure that your project does not have a
+`.gitlab-ci.yml` present. If present, your CI/CD configuration takes
+precedence over the Auto DevOps pipeline.
 
-- [Auto Browser Performance Testing](stages.md#auto-browser-performance-testing)
-- [Auto Build](stages.md#auto-build)
-- [Auto Code Intelligence](stages.md#auto-code-intelligence)
-- [Auto Code Quality](stages.md#auto-code-quality)
-- [Auto Container Scanning](stages.md#auto-container-scanning)
-- [Auto DAST (Dynamic Application Security Testing)](stages.md#auto-dast)
-- [Auto Dependency Scanning](stages.md#auto-dependency-scanning)
-- [Auto Deploy](stages.md#auto-deploy)
-- [Auto License Compliance](stages.md#auto-license-compliance)
-- [Auto Monitoring](stages.md#auto-monitoring)
-- [Auto Review Apps](stages.md#auto-review-apps)
-- [Auto SAST (Static Application Security Testing)](stages.md#auto-sast)
-- [Auto Secret Detection](stages.md#auto-secret-detection)
-- [Auto Test](stages.md#auto-test)
+To enable Auto DevOps for a project:
 
-As Auto DevOps relies on many different components, you should have a basic
-knowledge of the following:
+1. Go to your project's **Settings > CI/CD > Auto DevOps**.
+1. Select the **Default to Auto DevOps pipeline**.
+1. (Recommended) Add the [base domain](requirements.md#auto-devops-base-domain).
+1. (Recommended) Choose the [deployment strategy](requirements.md#auto-devops-deployment-strategy).
+1. Select **Save changes**.
 
-- [Kubernetes](https://kubernetes.io/docs/home/)
-- [Helm](https://helm.sh/docs/)
-- [Docker](https://docs.docker.com)
-- [GitLab Runner](https://docs.gitlab.com/runner/)
-- [Prometheus](https://prometheus.io/docs/introduction/overview/)
+GitLab triggers the Auto DevOps pipeline on the default branch.
 
-Auto DevOps provides great defaults for all the stages and makes use of
-[CI templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates). You can, however,
-[customize](customize.md) almost everything to your needs, and
-[manage Auto DevOps with GitLab APIs](customize.md#extend-auto-devops-with-the-api).
+To disable it, follow the same process and deselect **Default to Auto
+DevOps pipeline**.
 
-For an overview on the creation of Auto DevOps, read more
-[in this blog post](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/).
+#### At the group level
 
-NOTE:
-Kubernetes clusters can [be used without](../../user/project/clusters/index.md)
-Auto DevOps.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52447) in GitLab 11.10.
 
-## Kubernetes requirements
+When you enable Auto DevOps at group level, the subgroups and projects in that
+group inherit the configuration. This saves you time by batch-enabling it
+rather than enabling individually for each subgroup or project.
 
-See [Auto DevOps requirements for Kubernetes](requirements.md#auto-devops-requirements-for-kubernetes).
+When enabled for a group, you can still disable Auto DevOps
+for the subgroups and projects where you don't want to use it.
 
-## Auto DevOps base domain
+Only GitLab administrators and group owners can enable or disable Auto DevOps
+at the group level.
 
-The Auto DevOps base domain is required to use
-[Auto Review Apps](stages.md#auto-review-apps), [Auto Deploy](stages.md#auto-deploy), and
-[Auto Monitoring](stages.md#auto-monitoring). You can define the base domain in
-any of the following places:
+To enable Auto DevOps for a group:
 
-- Either under the cluster's settings, whether for an instance,
-  [projects](../../user/project/clusters/gitlab_managed_clusters.md#base-domain) or
-  [groups](../../user/group/clusters/index.md#base-domain)
-- Or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN`
-- Or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN`
-- Or as an instance-wide fallback in **Menu >** **{admin}** **Admin >**
-  **Settings > CI/CD** under the **Continuous Integration and Delivery** section.
+1. Go to your group's **Settings > CI/CD > Auto DevOps**.
+1. Select **Default to Auto DevOps pipeline**.
+1. Select **Save changes**.
 
-The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence
-as other environment [variables](../../ci/variables/index.md#cicd-variable-precedence).
-If this variable isn't set and the cluster setting is left blank, the instance-wide domain is used if set for your instance.
+After enabling Auto DevOps at the group level, you can trigger the
+Auto DevOps pipeline for any project that belongs to that group. To do so:
 
-Auto DevOps requires a wildcard DNS A record matching the base domain(s). For
-a base domain of `example.com`, you'd need a DNS entry like:
+1. Go to the project's homepage.
+1. Make sure the project doesn't contain a `.gitlab-ci.yml` file.
+1. From the project's sidebar, go to **CI/CD > Pipelines**.
+1. Select **Run pipeline** to trigger the Auto DevOps pipeline.
 
-```plaintext
-*.example.com   3600     A     1.2.3.4
-```
+To disable Auto DevOps on the group level, follow the same process and
+deselect **Default to Auto DevOps pipeline**.
 
-In this case, the deployed applications are served from `example.com`, and `1.2.3.4`
-is the IP address of your load balancer; generally NGINX ([see requirements](requirements.md)).
-Setting up the DNS record is beyond the scope of this document; check with your
-DNS provider for information.
+#### At the instance level **(FREE SELF)**
 
-Alternatively, you can use free public services like [nip.io](https://nip.io)
-which provide automatic wildcard DNS without any configuration. For [nip.io](https://nip.io),
-set the Auto DevOps base domain to `1.2.3.4.nip.io`.
+By enabling Auto DevOps in the instance level, all projects created in that
+instance become enabled. This is convenient when you want to run Auto DevOps by
+default for all projects. You can still disable Auto DevOps individually for
+the groups and projects where you don't want to run it.
 
-After completing setup, all requests hit the load balancer, which routes requests
-to the Kubernetes pods running your application.
+Only GitLab administrators can enable or disable Auto DevOps in the instance
+level.
 
-### AWS ECS
+Even when disabled for an instance, group owners and project maintainers
+can still enable Auto DevOps at the group and project levels.
 
-See [Auto DevOps requirements for Amazon ECS](requirements.md#auto-devops-requirements-for-amazon-ecs).
+To enable Auto DevOps for your instance:
 
-## Use multiple Kubernetes clusters
+1. From the top bar, select **Menu >** **{admin}** **Admin**.
+1. Go to **Settings > CI/CD > Continuous Integration and Deployment**.
+1. Select **Default to Auto DevOps pipeline**.
+1. (Optional) Add the Auto DevOps [base domain](requirements.md#auto-devops-base-domain).
+1. Select **Save changes**.
 
-When using Auto DevOps, you can deploy different environments to
-different Kubernetes clusters, due to the 1:1 connection
-[existing between them](../../user/project/clusters/multiple_kubernetes_clusters.md).
+When enabled, it attempts to run Auto DevOps pipelines in every project. If the
+pipeline fails in a particular project, it disables itself.
+GitLab administrators can change this in the [Auto DevOps settings](../../user/admin_area/settings/continuous_integration.md#auto-devops).
 
-The [Deploy Job template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)
-used by Auto DevOps defines 3 environment names:
+If a [CI/CD configuration file](../../ci/yaml/index.md) is present,
+it remains unchanged and Auto DevOps doesn't affect it.
 
-- `review/` (every environment starting with `review/`)
-- `staging`
-- `production`
+To disable Auto DevOps in the instance level, follow the same process
+and deselect the **Default to Auto DevOps pipeline** checkbox.
 
-Those environments are tied to jobs using [Auto Deploy](stages.md#auto-deploy), so
-except for the environment scope, they must have a different deployment domain.
-You must define a separate `KUBE_INGRESS_BASE_DOMAIN` variable for each of the above
-[based on the environment](../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable).
+### Quick start
 
-The following table is an example of how to configure the three different clusters:
+To guide your through the process of setting up Auto DevOps to deploy to a Kubernetes cluster on
+Google Kubernetes Engine (GKE), see the [quick start guide](quick_start_guide.md).
 
-| Cluster name | Cluster environment scope | `KUBE_INGRESS_BASE_DOMAIN` variable value | Variable environment scope | Notes |
-|--------------|---------------------------|-------------------------------------------|----------------------------|---|
-| review       | `review/*`                | `review.example.com`                      | `review/*`                 | The review cluster which runs all [Review Apps](../../ci/review_apps/index.md). `*` is a wildcard, used by every environment name starting with `review/`. |
-| staging      | `staging`                 | `staging.example.com`                     | `staging`                  | (Optional) The staging cluster which runs the deployments of the staging environments. You must [enable it first](customize.md#deploy-policy-for-staging-and-production-environments). |
-| production   | `production`              | `example.com`                             | `production`               | The production cluster which runs the production environment deployments. You can use [incremental rollouts](customize.md#incremental-rollout-to-production). |
+You can also follow the quick start for the general steps, but deploy to
+[AWS ECS](requirements.md#auto-devops-requirements-for-amazon-ecs) instead.
 
-To add a different cluster for each environment:
+If you're a self-managed user, before deploying to GKE, a GitLab administrator needs to:
 
-1. Navigate to your project's **Infrastructure > Kubernetes clusters**.
-1. Create the Kubernetes clusters with their respective environment scope, as
-   described from the table above.
-1. After creating the clusters, navigate to each cluster and [install
-   Ingress](quick_start_guide.md#install-ingress). Wait for the Ingress IP address to be assigned.
-1. Make sure you've [configured your DNS](#auto-devops-base-domain) with the
-   specified Auto DevOps domains.
-1. Navigate to each cluster's page, through **Infrastructure > Kubernetes clusters**,
-   and add the domain based on its Ingress IP address.
+1. Configure the [Google OAuth 2.0 OmniAuth Provider](../../integration/google.md).
+1. Configure a cluster on GKE.
 
-After completing configuration, test your setup by creating a merge request.
-Verify whether your application deployed as a Review App in the Kubernetes
-cluster with the `review/*` environment scope. Similarly, you can check the
-other environments.
+## Upgrade Auto DevOps dependencies when updating GitLab
 
-[Cluster environment scope isn't respected](https://gitlab.com/gitlab-org/gitlab/-/issues/20351)
-when checking for active Kubernetes clusters. For multi-cluster setup to work with Auto DevOps,
-create a fallback cluster with **Cluster environment scope** set to `*`. A new cluster isn't
-required. You can use any of the clusters already added.
+When updating GitLab, you may need to upgrade Auto DevOps dependencies to
+match your new GitLab version:
 
-## Limitations
+- [Upgrading Auto DevOps resources](upgrading_auto_deploy_dependencies.md):
+  - Auto DevOps template.
+  - Auto Deploy template.
+  - Auto Deploy image.
+  - Helm.
+  - Kubernetes.
+  - Environment variables.
+- [Upgrading PostgreSQL](upgrading_postgresql.md).
 
-The following restrictions apply.
+## Limitations
 
 ### Private registry support
 
-No documented way of using private container registry with Auto DevOps exists.
-We strongly advise using GitLab Container Registry with Auto DevOps to
+We cannot guarantee that you can use a private container registry with Auto DevOps.
+
+We strongly advise you to use GitLab Container Registry with Auto DevOps to
 simplify configuration and prevent any unforeseen issues.
 
 ### Install applications behind a proxy
 
 The GitLab integration with Helm does not support installing applications when
-behind a proxy. Users who want to do so must inject their proxy settings
-into the installation pods at runtime, such as by using a
-[`PodPreset`](https://v1-19.docs.kubernetes.io/docs/concepts/workloads/pods/podpreset/):
+behind a proxy.
+
+To do so, inject proxy settings into the installation pods at runtime.
+For example, you can use a [`PodPreset`](https://v1-19.docs.kubernetes.io/docs/concepts/workloads/pods/podpreset/):
 
 ```yaml
 apiVersion: settings.k8s.io/v1alpha1
@@ -335,23 +284,6 @@ spec:
       value: "PUT_YOUR_HTTPS_PROXY_HERE"
 ```
 
-## Upgrade Auto DevOps dependencies when updating GitLab
-
-When updating GitLab, you may need to upgrade Auto DevOps dependencies to
-match your new GitLab version:
-
-- [Upgrading Auto DevOps resources](upgrading_auto_deploy_dependencies.md):
-  - Auto DevOps template.
-  - Auto Deploy template.
-  - Auto Deploy image.
-  - Helm.
-  - Kubernetes.
-  - Environment variables.
-- [Upgrading PostgreSQL](upgrading_postgresql.md).
-
 ## Troubleshooting
 
 See [troubleshooting Auto DevOps](troubleshooting.md).
-
-<!-- DO NOT ADD TROUBLESHOOTING INFO HERE -->
-<!-- Troubleshooting information has moved to troubleshooting.md -->