GitLab CI/CD: Pipeline as Code

WHY IT EXISTS: Before pipeline as code, build steps lived in opaque scripts on individual machines. If a developer joined the team or a server died, the knowledge of how to compile, test, and ship disappeared with it. GitLab CI/CD configuration exists to version control the entire delivery process inside the repository itself so that the code and the automation that moves it to production share the same lifecycle and history.

THE MENTAL MODEL: Think of the gitlab-ci.yml file as a factory blueprint taped to the repo. Each commit is a raw material shipment arriving at the loading dock. The blueprint defines stations: first compile, then test, then package, then deploy. GitLab Runners are the workers who read the blueprint and execute the tasks. If the blueprint changes, the factory changes on the next shipment without anyone rewiring the machinery manually.

HOW IT WORKS: The file lives at the repository root and is written in YAML. A pipeline is composed of stages which run sequentially, and jobs which run in parallel within a stage. A job is a shell script or set of commands executed inside a Docker container, virtual machine, or shell executor. You define variables, cache directories to speed up repeat builds, and artifacts to pass compiled binaries between stages. Rules, only, and except keywords act as traffic lights deciding whether a job runs for a specific branch, tag, or merge request. Runners pick up jobs via the GitLab API, execute them, and stream logs back to the merge request or pipeline view.

WHEN TO USE IT: Use this when you want continuous integration and delivery tied directly to Git workflow. It shines for teams already hosting code on GitLab who need automated testing on every merge request, container image builds on tag pushes, or staged deployments to staging and production environments. It is especially powerful when you manage your own runners because you can attach specialized hardware or private network access to specific jobs.

WHEN NOT TO USE IT: Do not use GitLab CI/CD if your organization is deeply invested in another platform like GitHub Actions or Jenkins with years of custom plugin development that would be expensive to migrate. Avoid it for one-off scripts that never touch repository code, because the overhead of runner setup and YAML debugging outweighs the benefit. Also skip it if you need complex dynamic pipelines generated at runtime without any static YAML anchor; while parent-child pipelines exist, they add indirection that can obscure failure points.

ONE CANONICAL EXAMPLE: A Ruby on Rails application might define three stages: build, test, deploy. The build job installs gems and creates a Docker image. The test job pulls that image, runs RSpec, and uploads coverage reports as artifacts. The deploy job uses the same image to push to a Kubernetes cluster, but only when the pipeline runs on the main branch because it carries a rules block restricting it to refs of type branch and names matching main. If the developer forgets that rules block on the deploy job, every feature branch push attempts a production deployment.