Don't Panic — GitLab CI/CD

GitLab CI/CD turns a commit into work: build it, test it, perhaps deploy it, then report the result where code review happens. Before this arrangement, CI was often another service to connect and persuade to recognize the same repository. GitLab keeps the scheduler beside the repository. Convenient is a lovely word until the configuration file hands you a small mountain.

That file is .gitlab-ci.yml. It defines a pipeline, the whole run for a commit, merge request, schedule, or manual action. Pipelines contain stages, and stages contain jobs. Jobs in one stage can run together. A runner performs each job's script. This is where tidy YAML becomes a real machine doing real work, so hosted versus self-managed runners is not a decorative decision.

Stage order is not the entire map. The needs keyword lets a job start when its actual dependencies finish instead of waiting for every job in an earlier stage. That can shorten feedback. It can also send a confused pipeline efficiently toward the wrong destination, so dependencies still need to match the data and results a job truly consumes.

CI/CD variables carry configuration into jobs. Non-sensitive values can live in YAML. Sensitive values belong in project settings, where GitLab can mask them in logs and protect them for protected branches or tags. Masking is a mitigation, not an invisibility cloak. A pipeline change can run a script that reads what it is permitted to read, so pipeline review is part of the production trust boundary.

For deployment, an environment records what is running in a named target such as staging or production. A manual job and a staging environment make a useful first guardrail: automation prepares the route while a person chooses when to take it. The Intro explains the pieces; Slides show the shape; Cheatsheet is the map; the Reference tab holds the exact YAML rules.

Don't Panic — GitLab CI/CD

Relevant careers