Learn GitLab CI/CD - Auto DevOps & the CI/CD Component Catalog

#Introduction

In episode 17 we built a gradual release strategy. But before talking strategy, there's a more fundamental problem at many companies: every project starts its pipeline from zero. Twenty teams, twenty different ways of writing lint, test, and deploy. The result: inconsistent security standards and pipelines that are hard to maintain. This episode presents GitLab's two weapons for that problem — Auto DevOps as a shortcut, and the Component Catalog for sharing best practices.

#GitLab Auto DevOps

Auto DevOps is a zero-configuration concept: GitLab detects the application type from the repository and immediately assembles a complete pipeline. Imagine buying a "full service" package at a workshop — the vehicle is inspected, oil changed, and tested without you having to explain each step. Likewise with Auto DevOps: once enabled, it produces a pipeline with automated phases.

The standard phases it provides:

Phase	Purpose
Auto Build	Builds a Docker image and pushes to the registry
Auto Test	Runs tests according to the stack
Auto Code Quality	Checks code quality
Auto Security	SAST, dependency, and container scanning
Auto Review Apps	Temporary environment per merge request
Auto Deploy	Deploys to Kubernetes
Auto Monitoring	Monitors the application

Enabling it is just flipping one toggle in project settings, or adding a template inside .gitlab-ci.yml:

Enable Auto DevOps via include

include:
  - template: Auto-DevOps.gitlab-ci.yml

After that, GitLab runs all phases automatically on every push. You can control behavior through variables — for example setting AUTO_DEVOPS_DEPLOY_STRATEGY to blue_green to change the deploy strategy, or disabling specific jobs with rules.

Warning

Auto DevOps isn't a replacement for understanding pipelines. It's a good starting point, but still read its pipeline results, because a failing job in the Auto Security phase will block deploy. For enterprise production, the components you write yourself are often more controlled.

#The CI/CD Component Catalog

Since its introduction, GitLab has offered a modern way to share pipeline code: the Component Catalog. The concept is like a code library: components are reusable pipeline blocks, versioned, and consumed via a single line of include. Each component contains one or several jobs, customizable inputs, and a validation schema.

Using a versioned component

include:
  - component: gitlab.com/components/security/secret-detection@1.4.0
  - component: my-org/components/terraform-apply@2.1.0
    inputs:
      tf_version: "1.9.0"

The include: component: syntax references a component at the namespace/project@version address. Versioning lets teams pin a specific version — major changes in version 2 won't break projects still using version 1. This is exactly like pinning npm dependencies in a package-lock.json file.

Tip

Always specify an explicit version when using a component from the Catalog. Using the latest version implicitly makes your pipeline fragile against changes you didn't see.

#Writing Your Own Component

Now let's write an internal component for cross-team consistency. The component project structure is very specific:

Component project structure

components/
└── my-org/
    └── terraform/
        ├── templates/
        │   └── terraform-plan.yml
        ├── spec.json
        └── README.md

The templates directory holds the job YAML, spec.json describes the inputs, and README.md documents usage. Example of a component wrapping Terraform planning:

templates/terraform-plan.yml

spec:
  inputs:
    tf_version:
      type: string
      default: "1.9.0"
 
terraform-plan:
  image: hashicorp/terraform:${inputs.tf_version}
  script:
    - terraform init
    - terraform plan -out=plan.tfplan
  artifacts:
    paths: [plan.tfplan]
    expire_in: 1 week

The spec.inputs block declares parameters users can override, and inside the job they're referenced as inputs.tf_version. Component consumers just write:

Using an internal component

include:
  - component: gitlab.com/my-org/terraform@1.2.0
    inputs:
      tf_version: "1.10.0"

Once the component is published to the Catalog (the project must be marked as a component project), every team in the company can use it. Now linting, security scanning, and deploys have one implementation, not twenty.

Note

For internal components, GitLab also supports referencing directly from other CI/CD variables, for example the address of a self-hosted instance — so components stay private and are only visible to your organization.

#Closing

Auto DevOps provides a complete pipeline without configuration: build, test, quality, security, and deploy.
Auto DevOps phases can be customized via variables and rules.
The Component Catalog enables using versioned jobs through a single include line.
Internal components are built with a templates, spec, and documentation structure.
Cross-team consistency is born from the same components being used everywhere.

In the next episode 19 we cover troubleshooting, debugging, and monitoring pipelines — how to trace failed pipelines and monitor runner health. See you there!