GitLab CI/CD is the continuous integration and delivery system built into GitLab. The official documentation describes it as “a continuous method of software development, where you continuously build, test, deploy, and monitor iterative code changes,” catching problems early so that code meets established standards before it reaches production. Because it ships as part of GitLab itself, the pipeline lives next to the source, the merge requests, and the issue tracker in one product.
The pipeline is configured through a single file named .gitlab-ci.yml, placed at the root of the repository. According to the docs, this YAML file “specifies the stages, jobs, and scripts to be executed during your CI/CD pipeline.” Keeping the configuration in the repository means the pipeline definition is version-controlled and reviewed alongside the application code, an expression of pipeline-as-code.
A pipeline is organized into stages and jobs. Stages define the order of execution, with common examples being build, test, and deploy, while jobs specify the individual tasks performed within each stage. Jobs in the same stage typically run in parallel, and the pipeline advances from one stage to the next as work succeeds, giving teams a clear, ordered view of how a change moves from commit toward deployment.
The actual work is carried out by runners, which the documentation describes as “the agents that run your jobs.” Runners can be hosted by GitLab or self-managed on a team’s own machines, and are available across Linux, Windows, and macOS. This separation lets a single GitLab instance drive builds across many different environments and hardware targets.
GitLab CI/CD reflects GitLab’s single-application philosophy, in which source control, code review, CI/CD, and operations are delivered as one integrated tool rather than assembled from separate services. By bundling a full pipeline engine with the repository, it helped popularize the pattern, later echoed by GitHub Actions, of defining and running the entire build and deploy process directly inside the code-hosting platform.