Move stage information to separate page

Split out the stages to a separate page to begin shortening the
AutoDevops page.

doc/README.md

@@ -279,7 +279,7 @@ The following documentation relates to the DevOps **Release** stage:
 
 | Release Topics                                                                                                                      | Description                                                                                                                           |
 |:------------------------------------------------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------|
-| [Auto Deploy](topics/autodevops/index.md#auto-deploy)                                                                               | Configure GitLab for the deployment of your application.                                                                              |
+| [Auto Deploy](topics/autodevops/stages.md#auto-deploy)                                                                               | Configure GitLab for the deployment of your application.                                                                              |
 | [Canary Deployments](user/project/canary_deployments.md) **(PREMIUM)**                                                              | Employ a popular CI strategy where a small portion of the fleet is updated to the new version first.                                  |
 | [Deploy Boards](user/project/deploy_boards.md) **(PREMIUM)**                                                                        | View the current health and status of each CI environment running on Kubernetes, displaying the status of the pods in the deployment. |
 | [Environments and deployments](ci/environments.md)                                                                                  | With environments, you can control the continuous deployment of your software within GitLab.                                          |

doc/ci/README.md

@@ -120,7 +120,7 @@ Its feature set is listed on the table below according to DevOps stages.
 | [Using Docker images](docker/using_docker_images.md) | Use GitLab and GitLab Runner with Docker to build and test applications. |
 |---+---|
 | **Release** ||
-| [Auto Deploy](../topics/autodevops/index.md#auto-deploy) | Deploy your application to a production environment in a Kubernetes cluster. |
+| [Auto Deploy](../topics/autodevops/stages.md#auto-deploy) | Deploy your application to a production environment in a Kubernetes cluster. |
 | [Building Docker images](docker/using_docker_build.md) | Maintain Docker-based projects using GitLab CI/CD. |
 | [Canary Deployments](../user/project/canary_deployments.md) **(PREMIUM)** | Ship features to only a portion of your pods and let a percentage of your user base to visit the temporarily deployed feature. |
 | [Deploy Boards](../user/project/deploy_boards.md) **(PREMIUM)** | Check the current health and status of each CI/CD environment running on Kubernetes. |

doc/ci/autodeploy/index.md

 ---
-redirect_to: '../../topics/autodevops/index.md#auto-deploy'
+redirect_to: '../../topics/autodevops/stages.md#auto-deploy'
 ---
 
-This document was moved to [another location](../../topics/autodevops/index.md#auto-deploy).
+This document was moved to [another location](../../topics/autodevops/stages.md#auto-deploy).

doc/ci/autodeploy/quick_start_guide.md

 ---
-redirect_to: '../../topics/autodevops/index.md#auto-deploy'
+redirect_to: '../../topics/autodevops/stages.md#auto-deploy'
 ---
 
-This document was moved to [another location](../../topics/autodevops/index.md#auto-deploy).
+This document was moved to [another location](../../topics/autodevops/stages.md#auto-deploy).

doc/ci/introduction/index.md

@@ -199,7 +199,7 @@ according to each stage (Verify, Package, Release).
    - Deploy your features behind [Feature Flags](../../user/project/operations/feature_flags.md). **(PREMIUM)**
    - Add release notes to any Git tag with [GitLab Releases](../../user/project/releases/index.md).
    - View of the current health and status of each CI environment running on Kubernetes with [Deploy Boards](../../user/project/deploy_boards.md). **(PREMIUM)**
-   - Deploy your application to a production environment in a Kubernetes cluster with [Auto Deploy](../../topics/autodevops/index.md#auto-deploy).
+   - Deploy your application to a production environment in a Kubernetes cluster with [Auto Deploy](../../topics/autodevops/stages.md#auto-deploy).
 
 With GitLab CI/CD you can also:
 

doc/development/auto_devops.md

@@ -18,12 +18,12 @@ which then defines jobs.
 
 Some jobs use images that are built from external projects:
 
-- [Auto Build](../topics/autodevops/index.md#auto-build) uses
+- [Auto Build](../topics/autodevops/stages.md#auto-build) uses
   [configuration](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Build.gitlab-ci.yml)
   in which the `build` job uses an image that is built using the
   [`auto-build-image`](https://gitlab.com/gitlab-org/cluster-integration/auto-build-image)
   project.
-- [Auto Deploy](../topics/autodevops/index.md#auto-deploy) uses
+- [Auto Deploy](../topics/autodevops/stages.md#auto-deploy) uses
   [configuration](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)
   in which the jobs defined in this template use an image that is built using the
   [`auto-deploy-image`](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image)

doc/topics/application_development_platform/index.md

@@ -47,10 +47,10 @@ that may lead to security problems and unintended use. This can be achieved by m
 which inform security teams and developers if there is something to consider changing in their apps
 before it is too late to create a preventative fix. The following features are included:
 
-- [Auto SAST (Static Application Security Testing)](../autodevops/index.md#auto-sast-ultimate)
-- [Auto Dependency Scanning](../autodevops/index.md#auto-dependency-scanning-ultimate)
-- [Auto Container Scanning](../autodevops/index.md#auto-container-scanning-ultimate)
-- [Auto DAST (Dynamic Application Security Testing)](../autodevops/index.md#auto-dast-ultimate)
+- [Auto SAST (Static Application Security Testing)](../autodevops/stages.md#auto-sast-ultimate)
+- [Auto Dependency Scanning](../autodevops/stages.md#auto-dependency-scanning-ultimate)
+- [Auto Container Scanning](../autodevops/stages.md#auto-container-scanning-ultimate)
+- [Auto DAST (Dynamic Application Security Testing)](../autodevops/stages.md#auto-dast-ultimate)
 
 ### Observability
 
@@ -58,5 +58,5 @@ Performance is a critical aspect of the user experience, and ensuring your appli
 responsibility. The Application Development Platform integrates key performance analytics and feedback
 into GitLab, automatically. The following features are included:
 
-- [Auto Monitoring](../autodevops/index.md#auto-monitoring)
+- [Auto Monitoring](../autodevops/stages.md#auto-monitoring)
 - [In-app Kubernetes Logs](../../user/project/clusters/kubernetes_pod_logs.md)

doc/topics/autodevops/quick_start_guide.md

@@ -144,33 +144,33 @@ The pipeline is split into 4 stages, each running a couple of jobs.
 ![Pipeline stages](img/guide_pipeline_stages_v12_3.png)
 
 In the **build** stage, the application is built into a Docker image and then
-uploaded to your project's [Container Registry](../../user/packages/container_registry/index.md) ([Auto Build](index.md#auto-build)).
+uploaded to your project's [Container Registry](../../user/packages/container_registry/index.md) ([Auto Build](stages.md#auto-build)).
 
 In the **test** stage, GitLab runs various checks on the application:
 
 - The `test` job runs unit and integration tests by detecting the language and
-  framework ([Auto Test](index.md#auto-test))
+  framework ([Auto Test](stages.md#auto-test))
 - The `code_quality` job checks the code quality and is allowed to fail
-  ([Auto Code Quality](index.md#auto-code-quality-starter)) **(STARTER)**
+  ([Auto Code Quality](stages.md#auto-code-quality-starter)) **(STARTER)**
 - The `container_scanning` job checks the Docker container if it has any
-  vulnerabilities and is allowed to fail ([Auto Container Scanning](index.md#auto-container-scanning-ultimate))
+  vulnerabilities and is allowed to fail ([Auto Container Scanning](stages.md#auto-container-scanning-ultimate))
 - The `dependency_scanning` job checks if the application has any dependencies
-  susceptible to vulnerabilities and is allowed to fail ([Auto Dependency Scanning](index.md#auto-dependency-scanning-ultimate)) **(ULTIMATE)**
+  susceptible to vulnerabilities and is allowed to fail ([Auto Dependency Scanning](stages.md#auto-dependency-scanning-ultimate)) **(ULTIMATE)**
 - The `sast` job runs static analysis on the current code to check for potential
-  security issues and is allowed to fail([Auto SAST](index.md#auto-sast-ultimate)) **(ULTIMATE)**
+  security issues and is allowed to fail([Auto SAST](stages.md#auto-sast-ultimate)) **(ULTIMATE)**
 - The `license_management` job searches the application's dependencies to determine each of their
-  licenses and is allowed to fail ([Auto License Compliance](index.md#auto-license-compliance-ultimate)) **(ULTIMATE)**
+  licenses and is allowed to fail ([Auto License Compliance](stages.md#auto-license-compliance-ultimate)) **(ULTIMATE)**
 
 NOTE: **Note:**
 As you might have noticed, all jobs except `test` are allowed to fail in the
 test stage.
 
 The **production** stage is run after the tests and checks finish, and it automatically
-deploys the application in Kubernetes ([Auto Deploy](index.md#auto-deploy)).
+deploys the application in Kubernetes ([Auto Deploy](stages.md#auto-deploy)).
 
 Lastly, in the **performance** stage, some performance tests will run
 on the deployed application
-([Auto Browser Performance Testing](index.md#auto-browser-performance-testing-premium)). **(PREMIUM)**
+([Auto Browser Performance Testing](stages.md#auto-browser-performance-testing-premium)). **(PREMIUM)**
 
 ---
 
@@ -260,7 +260,7 @@ Let's fix that:
 1. Write a commit message and click **Commit**.
 
 Now, if you go back to the merge request you should not only see the test passing, but
-also the application deployed as a [review app](index.md#auto-review-apps). You
+also the application deployed as a [review app](stages.md#auto-review-apps). You
 can visit it by following clicking the **View app** button. You will see
 the changes that we previously made.
 

doc/topics/web_application_firewall/quick_start_guide.md

@@ -150,12 +150,12 @@ The pipeline is split into a few stages, each running a couple of jobs.
 ![Pipeline stages](../autodevops/img/guide_pipeline_stages_v12_3.png)
 
 In the **build** stage, the application is built into a Docker image and then
-uploaded to your project's [Container Registry](../../user/packages/container_registry/index.md) ([Auto Build](../autodevops/index.md#auto-build)).
+uploaded to your project's [Container Registry](../../user/packages/container_registry/index.md) ([Auto Build](../autodevops/stages.md#auto-build)).
 
 In the **test** stage, GitLab runs various checks on the application.
 
 The **production** stage is run after the tests and checks finish, and it automatically
-deploys the application in Kubernetes ([Auto Deploy](../autodevops/index.md#auto-deploy)).
+deploys the application in Kubernetes ([Auto Deploy](../autodevops/stages.md#auto-deploy)).
 
 The **production** stage creates Kubernetes objects
 like a Deployment, Service, and Ingress resource. The

doc/user/application_security/container_scanning/index.md

@@ -15,7 +15,7 @@ two open source tools for Vulnerability Static Analysis for containers.
 
 You can take advantage of Container Scanning by either [including the CI job](#configuration) in
 your existing `.gitlab-ci.yml` file or by implicitly using
-[Auto Container Scanning](../../../topics/autodevops/index.md#auto-container-scanning-ultimate)
+[Auto Container Scanning](../../../topics/autodevops/stages.md#auto-container-scanning-ultimate)
 that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
 
 GitLab checks the Container Scanning report, compares the found vulnerabilities

doc/user/application_security/dast/index.md

@@ -24,7 +24,7 @@ for known vulnerabilities using Dynamic Application Security Testing (DAST).
 
 You can take advantage of DAST by either [including the CI job](#configuration) in
 your existing `.gitlab-ci.yml` file or by implicitly using
-[Auto DAST](../../../topics/autodevops/index.md#auto-dast-ultimate)
+[Auto DAST](../../../topics/autodevops/stages.md#auto-dast-ultimate)
 that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
 
 GitLab checks the DAST report, compares the found vulnerabilities between the source and target

doc/user/application_security/dependency_scanning/index.md

@@ -18,7 +18,7 @@ All dependencies are scanned, including the transitive dependencies (also known
 
 You can take advantage of Dependency Scanning by either [including the CI job](#configuration)
 in your existing `.gitlab-ci.yml` file or by implicitly using
-[Auto Dependency Scanning](../../../topics/autodevops/index.md#auto-dependency-scanning-ultimate)
+[Auto Dependency Scanning](../../../topics/autodevops/stages.md#auto-dependency-scanning-ultimate)
 that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
 
 GitLab checks the Dependency Scanning report, compares the found vulnerabilities

doc/user/application_security/sast/index.md

@@ -19,7 +19,7 @@ vulnerabilities using Static Application Security Testing (SAST).
 You can take advantage of SAST by doing one of the following:
 
 - [Including the CI job](#configuration) in your existing `.gitlab-ci.yml` file.
-- Implicitly using [Auto SAST](../../../topics/autodevops/index.md#auto-sast-ultimate) provided by
+- Implicitly using [Auto SAST](../../../topics/autodevops/stages.md#auto-sast-ultimate) provided by
   [Auto DevOps](../../../topics/autodevops/index.md).
 
 GitLab checks the SAST report, compares the found vulnerabilities between the
@@ -96,7 +96,7 @@ The [Security Scanner Integration](../../../development/integrations/secure.md)
 ## Configuration
 
 NOTE: **Note:**
-You don't have to configure SAST manually as shown in this section if you're using [Auto SAST](../../../topics/autodevops/index.md#auto-sast-ultimate)
+You don't have to configure SAST manually as shown in this section if you're using [Auto SAST](../../../topics/autodevops/stages.md#auto-sast-ultimate)
 provided by [Auto DevOps](../../../topics/autodevops/index.md).
 
 For GitLab 11.9 and later, to enable SAST you must [include](../../../ci/yaml/README.md#includetemplate)

doc/user/application_security/threat_monitoring/index.md

@@ -13,7 +13,7 @@ navigating to your project's **Security & Compliance > Threat Monitoring** page.
 GitLab supports statistics for the following security features:
 
 - [Web Application Firewall](../../clusters/applications.md#web-application-firewall-modsecurity)
-- [Container Network Policies](../../../topics/autodevops/index.md#network-policy)
+- [Container Network Policies](../../../topics/autodevops/stages.md#network-policy)
 
 ## Web Application Firewall
 

doc/user/clusters/applications.md

@@ -754,7 +754,7 @@ available configuration options.
 [Cilium](https://cilium.io/) is a networking plugin for Kubernetes
 that you can use to implement support for
 [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
-resources. For more information on [Network Policies](../../topics/autodevops/index.md#network-policy), see the documentation.
+resources. For more information on [Network Policies](../../topics/autodevops/stages.md#network-policy), see the documentation.
 
 Enable Cilium in the `.gitlab/managed-apps/config.yaml` file to install it:
 

doc/user/compliance/license_compliance/index.md

@@ -13,7 +13,7 @@ using License Compliance.
 
 You can take advantage of License Compliance by either [including the job](#configuration)
 in your existing `.gitlab-ci.yml` file or by implicitly using
-[Auto License Compliance](../../../topics/autodevops/index.md#auto-license-compliance-ultimate)
+[Auto License Compliance](../../../topics/autodevops/stages.md#auto-license-compliance-ultimate)
 that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
 
 GitLab checks the License Compliance report, compares the licenses between the

doc/user/index.md

@@ -88,7 +88,7 @@ it all at once, from one single project.
 Use built-in [GitLab CI/CD](../ci/README.md) to test, build, and deploy your applications
 directly from GitLab. No third-party integrations needed.
 
-- [GitLab Auto Deploy](../topics/autodevops/index.md#auto-deploy): Deploy your application out-of-the-box with GitLab Auto Deploy.
+- [GitLab Auto Deploy](../topics/autodevops/stages.md#auto-deploy): Deploy your application out-of-the-box with GitLab Auto Deploy.
 - [Review Apps](../ci/review_apps/index.md): Live-preview the changes introduced by a merge request with Review Apps.
 - [GitLab Pages](project/pages/index.md): Publish your static site directly from
   GitLab with GitLab Pages. You can build, test, and deploy any Static Site Generator with Pages.

doc/user/project/canary_deployments.md

@@ -44,7 +44,7 @@ Canary deployments require that you properly configure Deploy Boards:
 
 1. Follow the steps to [enable Deploy Boards](deploy_boards.md#enabling-deploy-boards).
 1. To track canary deployments you need to label your Kubernetes deployments and
-   pods with `track: canary`. To get started quickly, you can use the [Auto Deploy](../../topics/autodevops/index.md#auto-deploy)
+   pods with `track: canary`. To get started quickly, you can use the [Auto Deploy](../../topics/autodevops/stages.md#auto-deploy)
    template for canary deployments that GitLab provides.
 
 Depending on the deploy, the label should be either `stable` or `canary`.

doc/user/project/deploy_boards.md

@@ -81,7 +81,7 @@ To display the Deploy Boards for a specific [environment](../../ci/environments.
    `$CI_PROJECT_PATH_SLUG` are the values of the CI variables. This is so we can
    lookup the proper environment in a cluster/namespace which may have more
    than one. These resources should be contained in the namespace defined in
-   the Kubernetes service setting. You can use an [Autodeploy](../../topics/autodevops/index.md#auto-deploy) `.gitlab-ci.yml`
+   the Kubernetes service setting. You can use an [Autodeploy](../../topics/autodevops/stages.md#auto-deploy) `.gitlab-ci.yml`
    template which has predefined stages and commands to use, and automatically
    applies the annotations. Each project will need to have a unique namespace in
    Kubernetes as well. The image below demonstrates how this is shown inside
@@ -139,7 +139,7 @@ version of your application.
 
 ## Further reading
 
-- [GitLab Autodeploy](../../topics/autodevops/index.md#auto-deploy)
+- [GitLab Autodeploy](../../topics/autodevops/stages.md#auto-deploy)
 - [GitLab CI/CD environment variables](../../ci/variables/README.md)
 - [Environments and deployments](../../ci/environments.md)
 - [Kubernetes deploy example](https://gitlab.com/gitlab-examples/kubernetes-deploy)

doc/user/project/index.md

@@ -63,7 +63,7 @@ When you create a project in GitLab, you'll have access to a large number of
 - [GitLab CI/CD](../../ci/README.md): GitLab's built-in [Continuous Integration, Delivery, and Deployment](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) tool
   - [Container Registry](../packages/container_registry/index.md): Build and push Docker
   images out-of-the-box
-  - [Auto Deploy](../../topics/autodevops/index.md#auto-deploy): Configure GitLab CI/CD
+  - [Auto Deploy](../../topics/autodevops/stages.md#auto-deploy): Configure GitLab CI/CD
   to automatically set up your app's deployment
   - [Enable and disable GitLab CI/CD](../../ci/enable_or_disable_ci.md)
   - [Pipelines](../../ci/pipelines/index.md): Configure and visualize

doc/user/project/integrations/prometheus.md

@@ -76,7 +76,7 @@ The Prometheus server will [automatically detect and monitor](https://prometheus
 - `prometheus.io/port` to define the port of the metrics endpoint.
 - `prometheus.io/path` to define the path of the metrics endpoint. Defaults to `/metrics`.
 
-CPU and Memory consumption is monitored, but requires [naming conventions](prometheus_library/kubernetes.md#specifying-the-environment) in order to determine the environment. If you are using [Auto DevOps](../../../topics/autodevops/), this is handled automatically.
+CPU and Memory consumption is monitored, but requires [naming conventions](prometheus_library/kubernetes.md#specifying-the-environment) in order to determine the environment. If you are using [Auto DevOps](../../../topics/autodevops/index.md), this is handled automatically.
 
 The [NGINX Ingress](../clusters/index.md#installing-applications) that is deployed by GitLab to clusters, is automatically annotated for monitoring providing key response metrics: latency, throughput, and error rates.
 

doc/user/project/integrations/prometheus_library/nginx_ingress.md

@@ -55,4 +55,4 @@ Managing these settings depends on how NGINX Ingress has been deployed. If you h
 
 In order to isolate and only display relevant metrics for a given environment, GitLab needs a method to detect which labels are associated. To do this, GitLab will search for metrics with appropriate labels. In this case, the `ingress` label must `<CI_ENVIRONMENT_SLUG>`.
 
-If you have used [Auto Deploy](../../../../topics/autodevops/index.md#auto-deploy) to deploy your app, this format will be used automatically and metrics will be detected with no action on your part.
+If you have used [Auto Deploy](../../../../topics/autodevops/stages.md#auto-deploy) to deploy your app, this format will be used automatically and metrics will be detected with no action on your part.

doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md

@@ -55,4 +55,4 @@ Managing these settings depends on how NGINX Ingress has been deployed. If you h
 
 In order to isolate and only display relevant metrics for a given environment, GitLab needs a method to detect which labels are associated. To do this, GitLab will search for metrics with appropriate labels. In this case, the `upstream` label must be of the form `<KUBE_NAMESPACE>-<CI_ENVIRONMENT_SLUG>-*`.
 
-If you have used [Auto Deploy](../../../../topics/autodevops/index.md#auto-deploy) to deploy your app, this format will be used automatically and metrics will be detected with no action on your part.
+If you have used [Auto Deploy](../../../../topics/autodevops/stages.md#auto-deploy) to deploy your app, this format will be used automatically and metrics will be detected with no action on your part.

doc/user/project/merge_requests/code_quality.md

@@ -19,7 +19,7 @@ Code Quality:
   Quality](https://gitlab.com/gitlab-org/ci-cd/codequality) project using [default Code Climate configurations](https://gitlab.com/gitlab-org/ci-cd/codequality/-/tree/master/codeclimate_defaults).
 - Can make use of a [template](#example-configuration).
 - Is available with [Auto
-  DevOps](../../../topics/autodevops/index.md#auto-code-quality-starter).
+  DevOps](../../../topics/autodevops/stages.md#auto-code-quality-starter).
 - Can be extended through [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) or a [custom tool](#implementing-a-custom-tool).
 
 Going a step further, GitLab can show the Code Quality report right

doc/user/project/repository/web_editor.md

@@ -126,7 +126,7 @@ a blank `README.md` file to it, and creates and redirects you to a new branch
 based on the issue title.
 If your [project is already configured with a deployment service](../integrations/overview.md),
 such as Kubernetes, GitLab takes one step further and prompts you to set up
-[auto deploy](../../../topics/autodevops/index.md#auto-deploy)
+[auto deploy](../../../topics/autodevops/stages.md#auto-deploy)
 by helping you create a `.gitlab-ci.yml` file.
 
 After the branch is created, you can edit files in the repository to fix