GitLab CI · DevOps & CI/CD Deep Dive

Anatomy

How a Pipeline Runs

Pipeline — defined in .gitlab-ci.yml at repo root.
Stages — ordered groups (build → test → deploy); jobs in a stage run in parallel.
Jobs — picked up by runners (shared SaaS, group, or self-hosted via the gitlab-runner agent).
Rules / only / except — gate jobs by branch, tag, file changes, MR target.
Environments — first-class concept: track which commit is on staging vs prod, with one-click rollback.
Includes & templates — include: from other repos or built-in templates (Auto DevOps, language-specific).

All-In-One

Container registry built in. No need for Docker Hub or ECR; $CI_REGISTRY_IMAGE is just there.
Security scans included. SAST, DAST, dependency scanning, license compliance — flip on, get JSON in the MR view.
Review apps — spin up an ephemeral env per MR for designers/PMs to click through.
Self-hosted is first class — many regulated/on-prem teams adopt GitLab specifically because the SaaS path is optional.
Auto DevOps — opinionated default pipeline that builds, tests, scans and deploys to Kubernetes with zero config.

Tradeoffs

Smaller marketplace than Actions — you'll write more shell yourself.
Self-hosted ops cost. The runner agent, registry, and database don't run themselves.
Tier gating. Many shiny features (compliance, advanced security) are locked behind Premium/Ultimate.
YAML can sprawl for multi-service monorepos — parent-child pipelines and include: help, but learning curve is real.

Continue