CI/CD Pipeline Design Cheat Sheet

Core principles and patterns for structuring continuous integration and delivery pipelines, from stages to caching and artifacts.

2 PagesAdvancedFeb 15, 2026

Typical Pipeline Stages

A common progression from commit to production.

Lint / Static Analysis- Fast checks (linters, type checkers) that fail cheaply before expensive stages run
Build- Compile code and produce a versioned, immutable artifact (binary, image, package)
Unit Tests- Fast, isolated tests run against the build on every commit
Integration/E2E Tests- Slower tests against real dependencies, often run on a subset of branches
Security Scan- SAST/dependency scanning (e.g. Trivy, Snyk) gating merges on critical findings
Deploy to Staging- Automated deploy of the same artifact to a production-like environment
Deploy to Production- Promotion of the exact tested artifact, often behind a manual approval gate

Example: GitHub Actions Pipeline

A concise CI workflow with caching and a build artifact.

yaml

name: CIon: [push, pull_request]jobs:  build-test:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - uses: actions/setup-node@v4        with:          node-version: 20          cache: 'npm'      - run: npm ci      - run: npm run lint      - run: npm test -- --ci      - run: npm run build      - uses: actions/upload-artifact@v4        with:          name: dist          path: dist/

Design Principles

What separates a reliable pipeline from a flaky one.

Build once, promote many- Build a single artifact and promote it unchanged through each environment, never rebuild per stage
Fail fast- Order cheap/fast checks (lint, unit tests) before slow ones (E2E, security scans)
Idempotent deploys- Re-running a deploy step should produce the same end state, not duplicate side effects
Immutable artifacts- Tag builds with a commit SHA or version, never overwrite 'latest' as the deploy source of truth
Parallelization- Run independent jobs (lint, unit tests, security scan) concurrently to shorten pipeline time
Environment parity- Keep staging as close to production as feasible to catch environment-specific bugs early

Pro Tip

Build your deployable artifact exactly once per commit and pass that same artifact through every downstream stage — rebuilding at each stage risks deploying code that was never actually tested.

Was this cheat sheet helpful?

Make & Makefiles Cheat Sheet

Blue-Green Deployment Cheat Sheet