What is CI/CD?
Continuous Integration (CI) is the practice of automatically building and testing every change that enters a shared repository. The goal is to surface integration bugs as early — and as cheaply — as possible, long before they reach production. Continuous Delivery / Deployment (CD) extends CI by automatically promoting validated artefacts through staging environments and, optionally, all the way to production without manual gates. Together, CI/CD pipelines act as the assembly line of software delivery: code goes in one end, a deployable artefact (container image, Helm chart, binary) comes out the other, with automated quality gates at every stage.Core Principles
Everything as Code
Infrastructure, pipelines, dashboards, and runbooks all live in version control. If it isn’t in a repo, it doesn’t exist.
Shift Left on Quality
Run linting, unit tests, SAST, and container scanning in CI — not after a manual code review or, worse, in production.
Immutable Artefacts
Build once, promote the same image or binary through every environment. Never rebuild for staging vs. production.
Fast Feedback Loops
A pipeline that takes 40 minutes is a pipeline nobody watches. Parallelise jobs, cache aggressively, fail fast.
Observability by Default
Metrics, logs, and traces should be baked into every service from day one — not added after the first outage.
Blameless Post-Mortems
When things go wrong (and they will), focus on systemic fixes and runbook improvements rather than individual blame.
The Typical Pipeline Lifecycle
Build
The pipeline compiles code, resolves dependencies, and produces a versioned artefact — usually a container image tagged with the commit SHA.
Test
Unit tests, integration tests, SAST scanning, and container image scanning all run in parallel where possible.
Package & Publish
The validated image is pushed to a container registry (ECR, GCR, GitLab Registry, Docker Hub).
Deploy to Staging
The CD stage applies the new image to a staging namespace, runs smoke tests, and waits for a health check.
CI/CD Tool Landscape
These notes focus on the tools used most heavily in practice, but the mental models apply across the ecosystem:| Tool | Strengths | Typical Use Case |
|---|---|---|
| GitLab CI | Tight SCM integration, built-in registry | Monorepos, self-hosted GitLab |
| Jenkins | Maximum flexibility via plugins | Legacy enterprise environments |
| Tekton | Kubernetes-native, reusable Tasks | Cloud-native / GitOps shops |
| GitHub Actions | Huge marketplace, easy onboarding | GitHub-hosted projects |
| Concourse | Stateless pipelines, reproducible | Strict reproducibility requirements |
| Bamboo / GoCD | Atlassian ecosystem, value-stream maps | Jira-centric organisations |
These notes don’t aim to be exhaustive reference documentation — the official docs do that better. The goal is to capture the 20 % of knowledge that covers 80 % of real-world tasks, plus the hard-won tricks that official docs rarely mention.
What’s Covered Here
GitLab CI/CD
Pipeline structure, Docker-in-Docker, caching strategies, and a full build-and-push workflow.
Docker
Essential commands, Dockerfile best practices, multi-stage builds, Compose, and networking.
Kubernetes
kubectl recipes, pod troubleshooting, ConfigMaps, resource limits, and rolling updates.
Related Sections
Cloud & Infrastructure
Terraform, AWS, GCP/Azure, and FinOps patterns that sit above the CI/CD layer.
Linux Essentials
The shell skills that underpin every pipeline script and container entrypoint.