1. What Is CI/CD?
Continuous Integration (CI) is the practice of merging code changes into a shared branch frequently, with each merge automatically built and tested. Continuous Delivery (CD) extends this by automatically preparing that tested code for release, and Continuous Deployment goes one step further by pushing it straight to production without manual approval.
Think of it as a factory assembly line for software: every change enters at one end, passes through a series of automated quality checks, and — if it passes all of them — comes out the other end ready to ship.
2. The Full Pipeline, Visualized
Figure 1 — A typical six-stage CI/CD pipeline. Each stage is a gate: code only proceeds if it passes.
3. Stage-by-Stage Breakdown
📝 Commit
A developer pushes code to a shared repository (e.g. GitHub, GitLab). This triggers the pipeline via a webhook. Best practice: commit small, frequent changes rather than large batches — smaller diffs are easier to test and debug.
🔨 Build
The CI server compiles the code (or bundles it, for interpreted languages) and resolves dependencies. A failed build here means the code doesn't even compile — the fastest and cheapest failure to catch.
✅ Test
Automated tests run in layers:
| Test type | Speed | What it checks |
|---|---|---|
| Unit tests | Fast | Individual functions/classes in isolation |
| Integration tests | Medium | Components working together (DB, APIs) |
| End-to-end tests | Slow | Full user flows through the real system |
📦 Package
Tested code is packaged into a deployable artifact — a Docker image, a JAR file, a compiled binary, or a set of static assets — and pushed to an artifact registry (Docker Hub, Artifactory, ECR).
🧪 Stage / QA
The artifact is deployed to a staging environment that mirrors production. This is where manual QA, exploratory testing, or performance testing often happens before a release gate.
🚀 Deploy
The artifact goes live. Depending on maturity, this can be a manual click-to-deploy (Continuous Delivery) or fully automatic (Continuous Deployment).
4. Deployment Strategies
Figure 2 — Common strategies for rolling out a new deployment safely.
- Blue-Green: Two identical environments; traffic flips instantly. Easy rollback, but needs double the infrastructure momentarily.
- Canary: New version gets a small slice of live traffic first, expanding gradually. Limits blast radius of bugs.
- Rolling Update: Instances are replaced gradually. Efficient resource use, but rollback is slower than blue-green.
5. Example: GitHub Actions Pipeline
name: CI/CD Pipeline
on:
push:
branches: [main]
jobs:
build-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Build
run: npm run build
deploy:
needs: build-test
runs-on: ubuntu-latest
steps:
- name: Deploy to production
run: ./scripts/deploy.sh
The needs: build-test line enforces the gate — deployment only runs if the build and test job succeeds.
6. Key Principles
✔ Fail fast
Order pipeline stages from cheapest/fastest to most expensive/slowest, so failures are caught before wasting time and resources.
✔ Keep it deterministic
A pipeline run should produce the same result given the same input — avoid flaky tests and non-reproducible builds.
✔ Automate the gate, not the judgment
Automate checks (tests, linting, security scans) but keep human approval for high-risk production releases if needed.
✔ Make rollback trivial
Every deployment strategy should have a fast, well-tested path back to the previous known-good version.