diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-07-20 12:55:51 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-07-20 12:55:51 +0300 |
commit | e8d2c2579383897a1dd7f9debd359abe8ae8373d (patch) | |
tree | c42be41678c2586d49a75cabce89322082698334 /doc/topics/autodevops/index.md | |
parent | fc845b37ec3a90aaa719975f607740c22ba6a113 (diff) |
Add latest changes from gitlab-org/gitlab@14-1-stable-eev14.1.0-rc42
Diffstat (limited to 'doc/topics/autodevops/index.md')
-rw-r--r-- | doc/topics/autodevops/index.md | 84 |
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 --> |