GitLab CI/CD

Stages give a simple linear order: all jobs in one stage must finish before the next stage starts. That is easy to read, but slow when one job in a stage is much longer than the others, because everything waits for it. needs: declares direct dependencies between jobs, so a job starts as soon as the jobs it needs have finished, even if other jobs in earlier stages are still running. The pipeline becomes a directed acyclic graph. needs also controls which artifacts a job downloads. I start with stages for clarity and add needs where the critical path is long, for example letting deploy-docs start as soon as build-docs finishes.

Artifacts are job outputs that GitLab stores and passes to later jobs in the same pipeline, and that you can download from the UI: build folders, test reports, coverage. They are reliable; a later job that needs them will get them. Cache is a best-effort speed-up for things you can regenerate, such as node_modules or a package manager's download directory, shared between pipelines and stored per runner or in object storage. A job must work correctly with an empty cache. Use cache:key:files with the lockfile so the cache changes when dependencies change. If a job's correctness depends on the file, use an artifact.

Store them as CI/CD variables marked protected and masked, so they are only injected into pipelines running on protected branches or tags and are hidden in logs. Protect the main branch so only maintainers can push or merge. Make production a protected environment with deployment approvals, so only named people or groups can run deploy jobs. Run deploy jobs on a dedicated tagged runner in the production network, not on shared runners. Where possible, avoid static credentials entirely: use id_tokens to give the job a short-lived OIDC token that your cloud provider or Vault exchanges for temporary credentials limited to that project and branch.

The executor is how the runner actually runs a job. Shell runs commands directly on the runner host: fastest to set up, but no isolation between jobs, so I only use it for very trusted single-purpose machines. Docker runs every job in a fresh container from the job's image: good isolation, reproducible, and the usual default. Kubernetes creates a pod per job, which fits teams already running a cluster and wanting autoscaling. Docker-autoscaler or instance executors start cloud VMs on demand for strong isolation per job. For most teams I would pick the Docker executor on a couple of VMs, then move to Kubernetes or autoscaling when queue times become a problem.

GitLab offers several levels. Inside one file, extends: and YAML anchors reuse job definitions, and hidden jobs (names starting with a dot) act as templates. Across projects, include: pulls in YAML from another project, a remote URL or GitLab's own templates. The modern option is CI/CD components: versioned, reusable pipeline pieces published to the CI/CD Catalog, with spec: inputs that are typed and validated when the pipeline is created. A service then writes a few lines to include the component at a version and pass inputs. Pin versions so a change to the shared component does not break every project at once.

I would provide a small catalogue of CI/CD components (build, test, scan, deploy) maintained by a platform team, versioned with semantic tags and documented. Compliance-critical jobs such as SAST, dependency scanning and secret detection would be enforced centrally with pipeline execution policies or compliance frameworks, so projects cannot remove them. Runner fleets are split by trust: autoscaled shared runners for builds, protected runners for deploys, isolated runners inside production networks. Secrets come from Vault or the cloud through OIDC id_tokens, with claims bound to project path and protected refs. Environments are protected with approvals. The trade-off is autonomy: teams must be able to extend the standard pipeline with their own jobs, otherwise they fork it and the platform loses control.

Push-based means a CI job holds cluster credentials and runs kubectl or helm. It is simple, gives immediate feedback in the pipeline and works for servers as well as clusters. The downsides: CI needs powerful credentials, and drift between Git and the cluster goes unnoticed. Pull-based GitOps runs an agent inside the cluster that watches a configuration repository and applies changes. The cluster's credentials never leave it, drift is detected and corrected, and Git history is the audit trail. The costs are another system to run and an indirect feedback loop: CI only updates an image tag in Git. For Kubernetes at scale I lean towards GitOps with CI building and testing images; for a few VMs, push-based from a protected runner is perfectly reasonable.

Speed comes from doing less and doing it in parallel: needs: graphs, rules: changes: to skip unaffected work, test sharding with parallel:, dependency and Docker layer caching, and pre-built CI images that already contain toolchains. Reliability comes from determinism: pinned image versions, lockfiles, no reliance on external services in unit tests, and retries only for known transient infrastructure errors via retry: when:, never for failing tests. Flaky tests are tracked and quarantined with ownership. Measure with pipeline analytics and runner metrics, and set a budget, for example merge request pipelines under ten minutes at the median. The trade-off is maintenance: aggressive skipping can miss cross-service breakage, so pair it with full scheduled pipelines on the default branch.