GitLab CI/CD is the continuous-integration and delivery system built into GitLab. Because it ships as part of the same product as the repository, issues, and container registry, the pipeline lives right next to the code it builds - defined in a .gitlab-ci.yml file at the repo root and triggered on every push, merge request, or schedule. The tight integration is the main reason teams already on GitLab use it rather than a separate CI service like CircleCI.

Stages, jobs, and runners

A pipeline is organized into stages (build, test, deploy) that run in order; within a stage, jobs run in parallel. Each job executes on a runner - a process you can host yourself or use GitLab's shared runners - usually inside a Docker image you specify. A job that fails stops the pipeline, so a broken test blocks the deploy stage from running.

stages: [test, deploy]
test:
  stage: test
  image: python:3.12
  script:
    - pip install -r requirements.txt
    - pytest
deploy:
  stage: deploy
  script: ./deploy.sh
  only: [main]

Environments, artifacts, and the registry

GitLab CI/CD tracks environments (staging, production) with deployment history and rollback, passes artifacts and caches between jobs, and integrates the built-in container registry so a pipeline can build an image and push it without external credentials. Merge requests show pipeline status inline, gating merges on green builds - the kind of workflow integration that comes from CI and source control being one product.

Where it fits

GitLab CI/CD is the natural choice when your code already lives in GitLab and you want CI/CD, registry, and review in one place with minimal setup. For data work it commonly tests transformation and pipeline code, builds job images, and deploys to clusters. The tradeoff against standalone CI tools is that you're tied to GitLab; the upside is fewer moving parts and deeper integration.

Frequently asked questions

Where is a GitLab pipeline defined? In a .gitlab-ci.yml file at the repository root, versioned with the code and triggered on push, merge request, or schedule.

What is a runner? The agent that executes jobs - either GitLab's shared runners or your own self-hosted runners, typically running each job in a specified Docker image.

Why choose it over CircleCI? Tight, single-product integration with GitLab repos, merge requests, environments, and the container registry; CircleCI is the pick when you want CI decoupled from where code lives.