GitLab CI

What is GitLab CI/CD?

GitLab CI/CD is the continuous-integration and continuous-delivery system built directly into the GitLab platform. You define your pipeline in a .gitlab-ci.yml file committed to your repository, and GitLab automatically runs it on every push — building, testing, scanning, and deploying your code through defined stages and jobs. Because it’s part of GitLab itself (not a separate tool you bolt on), it’s tightly integrated with the rest of the platform: source control, merge requests, issue tracking, container registry, security scanning, and deployment environments all live in one place. It’s a direct peer to GitHub Actions, Jenkins, and CircleCI in the CI/CD landscape.

How it works — pipelines as code

The core model is pipeline-as-code: your entire build/test/deploy process is declared in the .gitlab-ci.yml file, versioned alongside your application, so the pipeline evolves with the code and every change is reviewable and reproducible. A pipeline is organized into stages (e.g., build → test → deploy) that run in sequence, each containing jobs that run in parallel within the stage. Jobs execute on GitLab Runners — agents that pick up jobs and run them, which can be GitLab-hosted (managed for you) or self-hosted (you run runners on your own infrastructure for control, security, or access to private resources). Each job typically runs in a clean container, gets the repo, runs its scripts, and passes or fails. This mirrors the general CI/CD concept — automatically integrating and testing every change to catch problems early, then automating the path to deployment — and GitLab layers on features like manual approval gates for production deploys, environments, review apps (spinning up a live preview per merge request), and built-in security/compliance scanning stages.

Where it fits — the integrated-platform tradeoff

GitLab CI/CD’s central value proposition is integration: because CI/CD, source control, registry, security scanning, and issue tracking are one product, you avoid the toil of wiring together separate tools and get a seamless experience where a merge request shows its pipeline, test results, and security findings inline. For teams already on GitLab (especially self-hosted GitLab, common in enterprises with strict data-control or air-gapped requirements — a real GitLab strength), its CI/CD is the natural, well-integrated choice. The honest tradeoffs mirror every “all-in-one platform vs best-of-breed” decision: the integrated approach is convenient and coherent but ties you to the GitLab ecosystem, whereas GitHub Actions has a larger third-party marketplace of pre-built actions and dominates open-source, and standalone tools may fit teams with heterogeneous stacks. The recurring practical mistakes are the usual CI/CD ones rather than GitLab-specific: putting secrets in the YAML instead of GitLab’s protected CI/CD variables/secrets management (committing credentials to the repo is a serious exposure); slow pipelines from not using caching, artifacts, and parallelism (a CI pipeline that takes 40 minutes kills the fast-feedback benefit CI exists for); over-broad runner permissions; and neglecting to scope self-hosted runner security (a runner that builds untrusted code with broad access is an attack surface). Used well — pipeline as versioned code, secrets managed properly, caching and parallelism tuned, security scanning built into stages — it delivers the fast, automated, integrated delivery pipeline that’s table stakes for modern software teams.

What people get wrong

• Secrets in .gitlab-ci.yml — pipeline config is committed to the repo; credentials belong in GitLab’s protected CI/CD variables/secrets, never hardcoded in the YAML.
• Slow, un-optimized pipelines: skipping caching, artifacts, and parallel jobs produces long pipelines that undermine the fast-feedback purpose of CI in the first place.
• Underscoping self-hosted runner security — runners execute your build code with whatever access they’re given; over-permissioned runners building untrusted changes are a real attack surface.

Primary source: GitLab CI/CD documentation