summaryrefslogtreecommitdiff
path: root/doc/topics/autodevops/index.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/topics/autodevops/index.md')
-rw-r--r--doc/topics/autodevops/index.md84
1 files changed, 50 insertions, 34 deletions
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index f2ce61044ef..beb5f6a58f6 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -9,9 +9,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
> - Introduced in GitLab 11.0 for general availability.
GitLab Auto DevOps helps to reduce the complexity of software delivery by
-setting up pipelines and integrations for you. Instead of requiring you to
-manually configure your entire GitLab environment, Auto DevOps configures
-many of these areas for you, including security auditing and vulnerability
+setting up pipelines and integrations for you. Auto DevOps configures
+GitLab CI/CD pipelines including security auditing and vulnerability
testing.
Using Auto DevOps, you can:
@@ -54,17 +53,17 @@ following levels:
| GitLab SaaS | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No |
| GitLab self-managed | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes |
-When you enable AutoDevOps for your instance, it attempts to run on all
-pipelines in each project, but will automatically disable itself for individual
+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).
-Since [GitLab 12.7](https://gitlab.com/gitlab-org/gitlab/-/issues/26655),
+[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.
-If a [CI/CD configuration file](../../ci/yaml/README.md) is present in the
-project, it isn't changed and won't be affected by Auto DevOps.
+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.
### At the project level
@@ -80,7 +79,7 @@ To enable it:
and choose the [deployment strategy](#deployment-strategy).
1. Click **Save changes** for the changes to take effect.
-After enabling the feature, an Auto DevOps pipeline is triggered on the `master` branch.
+After enabling the feature, an Auto DevOps pipeline is triggered on the default branch.
### At the group level
@@ -88,9 +87,8 @@ After enabling the feature, an Auto DevOps pipeline is triggered on the `master`
Only administrators and group owners can enable or disable Auto DevOps at the group level.
-When enabling or disabling Auto DevOps at group level, group configuration is
-implicitly used for the subgroups and projects inside that group, unless Auto DevOps
-is specifically enabled or disabled on the subgroup or project.
+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.
To enable or disable Auto DevOps at the group level:
@@ -103,7 +101,8 @@ To enable or disable Auto DevOps at the group level:
Even when disabled at the instance level, group owners and project maintainers
can still enable Auto DevOps at the group and project level, respectively.
-1. As an administrator, go to **Admin Area > Settings > CI/CD > Continuous Integration and Deployment**.
+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.
@@ -118,7 +117,7 @@ project's **Settings > CI/CD > Auto DevOps**. The following options
are available:
- **Continuous deployment to production**: Enables [Auto Deploy](stages.md#auto-deploy)
- with `master` branch directly deployed to production.
+ 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
@@ -128,7 +127,7 @@ are available:
[`INCREMENTAL_ROLLOUT_MODE`](customize.md#incremental-rollout-to-production) variables
to `1` and `manual`. This means:
- - `master` branch is directly deployed to staging.
+ - The default branch is directly deployed to staging.
- Manual actions are provided for incremental rollout to production.
NOTE:
@@ -137,12 +136,12 @@ to minimize downtime and risk.
## Quick start
-If you're using GitLab.com, see the [quick start guide](quick_start_guide.md)
-for setting up Auto DevOps with GitLab.com and a Kubernetes cluster on Google Kubernetes
+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).
If you use a self-managed instance of GitLab, you must configure the
-[Google OAuth2 OmniAuth Provider](../../integration/google.md) before
+[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.
@@ -173,7 +172,7 @@ NOTE:
Depending on your target platform, some features might not be available to you.
Comprised of a set of [stages](stages.md), Auto DevOps brings these best practices to your
-project in a simple and automatic way:
+project automatically:
- [Auto Browser Performance Testing](stages.md#auto-browser-performance-testing)
- [Auto Build](stages.md#auto-build)
@@ -222,18 +221,17 @@ The Auto DevOps base domain is required to use
[Auto Monitoring](stages.md#auto-monitoring). You can define the base domain in
any of the following places:
-- either under the cluster's settings, whether for an instance,
- [projects](../../user/project/clusters/index.md#base-domain) or
+- 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 **Admin Area > Settings > CI/CD** under the
- **Continuous Integration and Delivery** section
+- 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.
The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence
-as other environment [variables](../../ci/variables/README.md#cicd-variable-precedence).
-If the CI/CD variable is not set and the cluster setting is left blank, the instance-wide **Auto DevOps domain**
-setting is used if set.
+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.
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:
@@ -258,14 +256,14 @@ to the Kubernetes pods running your application.
See [Auto DevOps requirements for Amazon ECS](requirements.md#auto-devops-requirements-for-amazon-ecs).
-## Using multiple Kubernetes clusters
+## Use multiple Kubernetes clusters
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/index.md#multiple-kubernetes-clusters).
+[existing between them](../../user/project/clusters/multiple_kubernetes_clusters.md).
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 currently defines 3 environment names:
+used by Auto DevOps defines 3 environment names:
- `review/` (every environment starting with `review/`)
- `staging`
@@ -274,7 +272,7 @@ used by Auto DevOps currently defines 3 environment names:
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/README.md#limit-the-environment-scope-of-a-cicd-variable).
+[based on the environment](../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable).
The following table is an example of how to configure the three different clusters:
@@ -296,8 +294,8 @@ To add a different cluster for each environment:
1. Navigate to each cluster's page, through **Infrastructure > Kubernetes clusters**,
and add the domain based on its Ingress IP address.
-After completing configuration, you can test your setup by creating a merge request
-and verifying your application is deployed as a Review App in the Kubernetes
+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.
@@ -337,5 +335,23 @@ 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 -->