Master GitLab Auto DevOps: A Complete Guide to CI/CD Pipeline Stages

Including include: - template: Auto-DevOps.gitlab-ci.yml in a project's .gitlab-ci.yml activates GitLab Auto DevOps, which generates a full CI/CD pipeline automatically.

Auto DevOps Overview

Auto DevOps is a built‑in GitLab CI/CD template that follows the "convention over configuration" principle. It detects the project's language and framework, then runs a predefined series of jobs covering build, test, code‑quality, security scanning, packaging, deployment, and monitoring. Developers only need to commit code; the pipeline handles the rest.

Core Pipeline Stages

Build Stage

The build stage creates a runnable artifact for the application.

Mechanism Auto DevOps first looks for a Dockerfile in the repository root. If found, it runs docker build to produce a Docker image. If no Dockerfile exists, it falls back to Herokuish buildpacks, which automatically detect the language (Ruby, Node.js, Python, Java, Go, etc.) and package the app into a Docker image.

Output A Docker image is built and pushed to the project’s GitLab Container Registry, tagged with the commit SHA for traceability.

How to use Provide a custom Dockerfile for full control. If you prefer not to maintain a Dockerfile, ensure the project follows the language‑specific buildpack conventions.

Test Stage

The test stage runs a set of parallel jobs that verify code quality and security.

Core checks

Code Quality – analyzes maintainability and style issues.

SAST – static application security testing for common vulnerabilities.

Secret Detection – scans for accidentally committed passwords, API keys, etc.

Dependency Scanning – inspects files such as package.json or Gemfile.lock for known vulnerable libraries.

Container Scanning – examines the Docker image built in the previous stage for OS‑level security risks.

How to use These jobs run automatically; results are aggregated into the Merge Request widget, allowing reviewers to see new issues before merging.

Review Stage

This stage creates a temporary "Review App" environment for each Merge Request.

Mechanism When a MR is opened or updated, the review job deploys the Docker image to a dynamically provisioned environment (typically a Kubernetes cluster). A unique URL is provided for live interaction.

Value Stakeholders can interact with the live feature, improving communication and delivery quality.

How to use The project must be linked to a Kubernetes cluster via Operations > Kubernetes in GitLab. Once configured, each MR automatically triggers a Review App and displays its URL in the MR. The environment is destroyed when the MR is closed or merged.

DAST Stage

After the Review App is up, Auto DevOps runs Dynamic Application Security Testing (DAST) against the live application.

Mechanism DAST performs black‑box testing by simulating attacks on the running Review App, uncovering runtime vulnerabilities that static analysis may miss.

How to use The stage runs automatically; its report is merged into the MR security dashboard to aid merge decisions.

Staging & Production Stages

When a MR is merged into the main branch (e.g., main or master), the pipeline proceeds to deployment.

Mechanism By default, code is first deployed to a staging environment for final verification (usually triggered manually). After validation, the production job can be manually triggered to deploy the app to the live environment.

How to use Both stages require a configured Kubernetes cluster. Deployment strategies can be customized via GitLab environment variables, enabling replica count adjustments, canary releases, or other advanced patterns.

Customization & Control

All Auto DevOps jobs are visible and can be overridden. Teams can replace or extend any stage by adding their own jobs to .gitlab-ci.yml, adjusting variables, or disabling specific scans. This makes Auto DevOps suitable for both novice teams seeking out‑of‑the‑box automation and experienced teams that need fine‑grained control.