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 automatically runs jobs when you push code. You write a `.gitlab-ci.yml` file describing what to do (run tests, build the app, deploy it), and GitLab's servers execute those steps and report back whether everything passed.
At work
Teams using GitLab for code hosting use GitLab CI to automate testing and deployment. Every merge request triggers automated checks; passing pipelines are a prerequisite for merging. Failures are visible directly in the merge request interface.
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 CI includes SAST (Static Application Security Testing), DAST (Dynamic testing), dependency scanning, container scanning, and secret detection as built-in pipeline jobs. Review Apps deploy merge request branches to temporary URLs. Environments track deployment status across staging and production with rollback controls.
At home
GitLab's `.gitlab-ci.yml` supports include directives to share pipeline templates across projects, rules to conditionally include jobs, and needs dependencies to create DAG (directed acyclic graph) pipelines that start subsequent jobs as soon as their dependencies complete rather than waiting for an entire stage.
At work
Enterprise GitLab deployments use Compliance Pipelines to enforce security scans regardless of project configuration, Group-level runners for shared infrastructure, and GitLab's Kubernetes Agent for secure cluster access without exposing API endpoints. Pipeline efficiency is tracked with GitLab's Value Stream Analytics, which measures cycle time from code commit to production deployment.
Real-world examples
At home
Marcus uses GitLab CI for his personal projects because the free tier includes unlimited private repos and 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.