GitLab CI
yml` file in a repository. It defines pipelines made of stages and jobs that run on GitLab Runners, automating tasks like building, testing, and deploying code on every commit, merge request, or scheduled trigger.
Definition
GitLab CI/CD is the continuous integration and delivery system built into GitLab, configured via a `.gitlab-ci.yml` file in a repository. It defines pipelines made of stages and jobs that run on GitLab Runners, automating tasks like building, testing, and deploying code on every commit, merge request, or scheduled trigger.
Overview
GitLab CI/CD is deeply integrated into the GitLab platform itself, rather than being a bolt-on or separate product, which lets pipeline results, test reports, and deployment status appear directly in merge requests and the repository UI. A pipeline is defined declaratively in YAML: jobs are grouped into stages (e.g. build, test, deploy) that run sequentially by default, while jobs within the same stage run in parallel. Jobs execute on GitLab Runners — agents that can run on GitLab's shared SaaS infrastructure or be self-hosted on a company's own servers, VMs, or Kubernetes cluster. Runners execute jobs inside configurable environments (Docker containers, shell executors, Kubernetes pods), giving teams control over build environments and enabling caching and artifact passing between jobs. GitLab CI/CD supports advanced pipeline features: DAG (directed acyclic graph) pipelines for job dependencies not tied to strict stage order, `rules`/`only`/`except` for conditional job execution, merge request pipelines, parent-child and multi-project pipelines, environments and deployment tracking (including manual approval gates), and built-in security scanning (SAST, dependency scanning, container scanning) as part of GitLab's DevSecOps positioning. Because CI/CD, source control, issue tracking, and container/package registries all live in one GitLab instance, teams often adopt it for tighter integration compared to assembling separate tools (e.g. GitHub + Jenkins + a separate registry).
Key Features
- Pipelines defined declaratively in a `.gitlab-ci.yml` file
- Stages and jobs, with parallel execution within a stage
- GitLab Runners: SaaS-hosted or self-hosted execution agents
- DAG pipelines for dependency-based (non-linear) job ordering
- Built-in artifact and cache management between jobs
- Merge request pipelines and deployment environment tracking
- Integrated security scanning (SAST, DAST, dependency, container scanning)
- Native integration with GitLab's container and package registries
Use Cases
Alternatives
History
GitLab CI/CD is the built-in continuous-integration and continuous-delivery system of the GitLab platform. It began as a separate side-project application that talked to GitLab through webhooks, and was then folded directly into the product: with the release of GitLab 8.0 in September 2015, GitLab CI became fully integrated, so source control and pipelines lived in one application. Pipelines are defined declaratively in a .gitlab-ci.yml file in the repository and executed by GitLab Runners, covering build, test, and deployment stages. This tight integration of CI/CD with version control helped popularize the "single application for the whole DevOps lifecycle" approach.
Sources
- GitLab — Continuous Integration and Delivery (CI/CD) · as of 2026-07-17
- GitLab — "Getting started with GitLab and GitLab CI" (2015) · as of 2026-07-17