GitLab CI
Also known as: GitLab CI/CD, .gitlab-ci.yml, GitLab pipelines
GitLab CI/CD is GitLab's automation system for building, testing, and deploying code.
Defined in a `.gitlab-ci.yml` file, pipelines run automatically on code changes. GitLab CI is notable for its deep integration with GitLab's full DevSecOps platform: security scanning, container registry, and deployment environments all built in.
GitLab CI, explained at three levels
At home
GitLab CI is like an assembly line manager reading a checklist taped to your project. The checklist is a file called .gitlab-ci.yml listing stages such as build, test, and deploy. Every time you push code, GitLab hands each step to a worker machine called a runner, which follows the instructions and reports back, so you see a pass or fail on every change.
At work
GitLab CI/CD is the automation engine built into GitLab. On each push or merge request it runs a pipeline of jobs, such as tests, security scans, and deployments, and shows the results in the merge request so failing code can be blocked from merging. Businesses care because code, pipelines, security findings, and deployment history live in one tool, which simplifies audits and cuts integration work.
At home
GitLab CI uses Runners (agents that execute jobs) which can be GitLab-hosted (shared runners) or self-hosted. Pipelines are defined as stages (build, test, deploy) with jobs in each stage. Jobs in the same stage run in parallel; the next stage only starts when all jobs in the current stage pass.
At work
GitLab adds security and delivery features as pipeline jobs. Templates for SAST (static code analysis), DAST (testing a running app), dependency scanning, container scanning, and secret detection drop findings into the merge request, with some scanners limited to the paid Ultimate tier. Environments record which version runs in staging or production and support rollback, and Review Apps deploy each merge request to a temporary URL so reviewers can click through changes.
At home
Large pipelines rely on a few .gitlab-ci.yml features. The include keyword pulls shared templates from other projects, extends reuses job definitions, and rules decide whether a job runs based on branch, changed files, or variables. The needs keyword turns stages into a DAG (directed acyclic graph), so a job starts as soon as its dependencies finish instead of waiting for the whole stage. In my view, needs is the biggest speed win most teams overlook.
At work
Enterprise GitLab enforces policy above individual projects. Pipeline execution policies, which replace the older compliance pipelines, inject mandatory jobs such as security scans into every project's pipeline, and merge request approval policies block merges when scans find serious issues. Group-level runners share build capacity, and the GitLab agent for Kubernetes connects clusters from the inside, so their API isn't exposed. Value Stream Analytics measures time from commit to production to spot bottlenecks.
Real-world examples
At home
Marcus uses GitLab CI for his personal projects because the free tier includes private repositories and a monthly allowance of CI minutes. His pipeline runs tests, builds a Docker image, and pushes it to GitLab's built-in container registry.
At work
Fatima's company runs self-hosted GitLab for compliance reasons. Their CI pipeline includes mandatory SAST scans and secret detection; pipelines fail automatically if a security issue is found, preventing vulnerable code from merging.
Common confusions
- GitLab CI and GitHub Actions are the same — Both automate software pipelines, but GitLab CI is integrated with GitLab's full DevSecOps platform (security scanning, environments, container registry). GitHub Actions integrates with GitHub's ecosystem. Teams choose based on which code hosting platform they use.
- GitLab is only for large enterprises — GitLab has a generous free tier and is widely used by individual developers and small teams. The self-hosted option (GitLab Community Edition) is free and open-source.
For analysts
GitLab CI's scheduled pipelines can automate data refreshes (run a Python script nightly, update a report, and post results to a Slack channel) treating data workflows with the same reliability controls as software deployments.
History & origin
GitLab launched its CI system in 2012, before GitHub Actions existed. GitLab's approach was 'single application for the entire DevOps lifecycle': source code, CI/CD, container registry, security scanning, and deployment monitoring in one product. GitLab CI was among the first to popularize pipeline-as-code with YAML files and to offer integrated Docker container builds. Many enterprises choose GitLab for self-hosted deployments with more control than GitHub.