debian-mirror-gitlab/doc/topics/autodevops/index.md

stage	group	info
Configure	Configure	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments

Auto DevOps (FREE)

• 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. Auto DevOps configures GitLab CI/CD pipelines including security auditing and vulnerability testing.

Using Auto DevOps, you can:

• 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.
• 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 and tools, Auto DevOps lets you push your code, with GitLab doing the rest, improving your productivity and efficiency.

For an introduction to Auto DevOps, watch AutoDevOps in GitLab 11.0 or see this overview.

For requirements, read Requirements for Auto DevOps for more information.

For GitLab contributors, see the Auto DevOps development guide.

Enable or disable Auto DevOps

Auto DevOps is enabled by default for all projects in self-managed instances (as of GitLab 11.3), but not for GitLab SaaS instances.

When first using Auto DevOps, review the requirements to ensure all the necessary components to make full use of Auto DevOps are available. First-time users should follow the quick start guide.

Depending on your instance type, you can enable or disable Auto DevOps at the following levels:

Instance type	Project	Group	Instance (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

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.

Introduced in GitLab 12.7, Auto DevOps runs on pipelines automatically only if a Dockerfile or matching buildpack exists.

If a CI/CD configuration file is present in the project, it remains unchanged and Auto DevOps doesn't affect it.

At the project level

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.

To enable it:

1. Go to your project's Settings > CI/CD > Auto DevOps.
2. Select the Default to Auto DevOps pipeline checkbox to enable it.
3. (Optional, but recommended) When enabling, you can add in the base domain Auto DevOps uses to deploy your application, and choose the deployment strategy.
4. Click Save changes for the changes to take effect.

After enabling the feature, an Auto DevOps pipeline is triggered on the default branch.

At the group level

• Introduced in GitLab 11.10.

Only administrators and group owners can enable or disable Auto DevOps at the group level.

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:

1. Go to your group's Settings > CI/CD > Auto DevOps page.
2. Select the Default to Auto DevOps pipeline checkbox to enable it.
3. Click Save changes for the changes to take effect.

At the instance level (FREE SELF)

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, on the top bar, select Menu > {admin} Admin.
2. Go to Settings > CI/CD > Continuous Integration and Deployment.
3. Select Default to Auto DevOps pipeline for all projects to enable it.
4. (Optional) You can set up the Auto DevOps base domain, for Auto Deploy and Auto Review Apps to use.
5. Click Save changes for the changes to take effect.

Deployment strategy

• Introduced in GitLab 11.0.

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:

• Continuous deployment to production: Enables Auto Deploy with the default branch directly deployed to production.

• Continuous deployment to production using timed incremental rollout: Sets the INCREMENTAL_ROLLOUT_MODE 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 and INCREMENTAL_ROLLOUT_MODE variables to 1 and manual. This means:

  • The default branch is directly deployed to staging.
  • Manual actions are provided for incremental rollout to production.

NOTE: Use the blue-green deployment technique to minimize downtime and risk.

Quick start

For GitLab.com users, see the quick start guide 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 OAuth 2.0 OmniAuth Provider before configuring a cluster on GKE. After configuring the provider, you can follow the steps in the quick start guide to get started.

In GitLab 13.0 and later, it is possible to leverage Auto DevOps to deploy to AWS ECS.

Comparison to application platforms and PaaS

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 and goes beyond it in multiple ways:

• 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).
• 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 documentation for more information.

Features

NOTE: Depending on your target platform, some features might not be available to you.

Comprised of a set of stages, Auto DevOps brings these best practices to your project automatically:

• Auto Browser Performance Testing
• Auto Build
• Auto Code Intelligence
• Auto Code Quality
• Auto Container Scanning
• Auto DAST (Dynamic Application Security Testing)
• Auto Dependency Scanning
• Auto Deploy
• Auto License Compliance
• Auto Monitoring
• Auto Review Apps
• Auto SAST (Static Application Security Testing)
• Auto Secret Detection
• Auto Test

As Auto DevOps relies on many different components, you should have a basic knowledge of the following:

• Kubernetes
• Helm
• Docker
• GitLab Runner
• Prometheus

Auto DevOps provides great defaults for all the stages and makes use of CI templates. You can, however, customize almost everything to your needs, and manage Auto DevOps with GitLab APIs.

For an overview on the creation of Auto DevOps, read more in this blog post.

NOTE: Kubernetes clusters can be used without Auto DevOps.

Kubernetes requirements

See Auto DevOps requirements for Kubernetes.

Auto DevOps base domain

The Auto DevOps base domain is required to use Auto Review Apps, Auto Deploy, and 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 or groups
• 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. 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:

*.example.com   3600     A     1.2.3.4

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). Setting up the DNS record is beyond the scope of this document; check with your DNS provider for information.

Alternatively, you can use free public services like nip.io which provide automatic wildcard DNS without any configuration. For nip.io, set the Auto DevOps base domain to 1.2.3.4.nip.io.

After completing setup, all requests hit the load balancer, which routes requests to the Kubernetes pods running your application.

AWS ECS

See Auto DevOps requirements for Amazon ECS.

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.

The Deploy Job template used by Auto DevOps defines 3 environment names:

• review/ (every environment starting with review/)
• staging
• production

Those environments are tied to jobs using 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.

The following table is an example of how to configure the three different clusters:

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. * 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.
production	production	example.com	production	The production cluster which runs the production environment deployments. You can use incremental rollouts.

To add a different cluster for each environment:

1. Navigate to your project's Infrastructure > Kubernetes clusters.
2. Create the Kubernetes clusters with their respective environment scope, as described from the table above.
3. After creating the clusters, navigate to each cluster and install Ingress. Wait for the Ingress IP address to be assigned.
4. Make sure you've configured your DNS with the specified Auto DevOps domains.
5. Navigate to each cluster's page, through Infrastructure > Kubernetes clusters, and add the domain based on its Ingress IP address.

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.

Cluster environment scope isn't respected 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.

Limitations

The following restrictions apply.

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 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:

apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
  name: gitlab-managed-apps-default-proxy
  namespace: gitlab-managed-apps
spec:
  env:
    - name: http_proxy
      value: "PUT_YOUR_HTTP_PROXY_HERE"
    - name: https_proxy
      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:
  • Auto DevOps template.
  • Auto Deploy template.
  • Auto Deploy image.
  • Helm.
  • Kubernetes.
  • Environment variables.
• Upgrading PostgreSQL.

Troubleshooting

See troubleshooting Auto DevOps.