CI/CD From Zero to Production

Why CI/CD Exists: The Problem It Solves

Picture a team of eight developers in 2005. Each works on a feature branch for six weeks. Release day arrives, and everyone merges at once. The build breaks. Two features conflict in ways nobody anticipated. Someone "just needs to fix one thing" and it takes three days. QA tests for two weeks. Deployment happens on a Saturday night, manually, from a 40-step Word document.

This is integration hell, and it has three root causes:

• Big batches. The larger a change, the harder it is to understand, test and debug.
• Late feedback. A bug found six weeks after it was written costs 10–100× more to fix than one found in six minutes.
• Manual, unrepeatable processes. Humans are inconsistent. Scripts are not.

Make small changes, verify them automatically, and ship them continuously, so that releasing software becomes boring.

Boring is the goal. Elite teams deploy dozens or hundreds of times a day not because they're reckless, but because each deployment is so small and so well verified that it carries almost no risk.

Core Concepts and Vocabulary

Continuous Integration (CI)

Developers merge small changes into a shared mainline at least daily. Every merge triggers an automated build and test run. The key outcome: the main branch is always in a known-good state.

Continuous Delivery (CD)

Every change that passes the pipeline is releasable. The artifact is built, tested, staged and ready, but a human presses the button to release to production.

Continuous Deployment

Every change that passes the pipeline is automatically released to production with no human gate. This requires strong automated testing, feature flags and observability.

Commit ──► Build ──► Test ──► Package ──► Deploy to Staging ──► Release
  │                                                                │
  └──────── Continuous Integration ───────┘                        │
  └──────────────── Continuous Delivery (manual release) ──────────┤
  └──────────────── Continuous Deployment (automatic release) ─────┘

The Golden Principles

1. Build once, deploy many. Build the artifact a single time and promote the same artifact through every environment.
2. Everything as code. Pipelines, infrastructure, config and policies live in version control.
3. Fail fast. Run the fastest, cheapest checks first.
4. Keep the pipeline fast. Over 10 minutes for CI feedback and developers stop waiting.
5. The pipeline is the only path to production. No SSH-and-hotfix.
6. Broken main is the top priority. Stop and fix it before anything else.

Designing the Foundation: Git, Branching & Repo Strategy

Choosing a Branching Strategy

Trunk-Based Development (recommended) — Developers commit to main frequently. Incomplete work is hidden behind feature flags. This is what DORA's top performers overwhelmingly use.

GitHub Flow — Short-lived feature branches, pull request, review, merge to main, deploy. Simple and effective.

GitFlow — develop, release/*, hotfix/* branches. Suits scheduled-release products but adds merge overhead. Avoid for web services.

Pull Request Hygiene

• Keep PRs small: ideally under 400 lines changed.
• Require at least one review and passing CI before merge.
• Use branch protection: no direct pushes to main.
• Use CODEOWNERS so the right experts review the right paths.

Conventional Commits

feat(auth): add passkey login          → minor bump (1.4.0 → 1.5.0)
fix(api): handle null customer id      → patch bump (1.5.0 → 1.5.1)
feat!: drop v1 endpoints               → major bump (1.5.1 → 2.0.0)

Continuous Integration in Depth

Anatomy of a Great CI Pipeline

A well-designed CI run is ordered from cheapest/fastest to most expensive:

1. Checkout & restore cache            (seconds)
2. Lint & format check                 (seconds)
3. Static analysis / type check        (seconds to a minute)
4. Unit tests                          (1–3 min)
5. Build                               (1–5 min)
6. Integration tests                   (3–8 min)
7. Security scans (SAST, deps, secrets)(parallel)
8. Package & publish artifact          (1 min)

CI Best Practices

1. Cache aggressively, but correctly. Cache dependencies keyed on lockfile hash.
2. Make builds hermetic and reproducible. Pin versions — lockfiles, digest-pinned base images.
3. Kill flaky tests ruthlessly. A flaky test teaches the team to ignore red builds.
4. Use ephemeral, clean environments. Each job should start from a clean slate.
5. Concurrency control. Cancel obsolete runs on the same branch.
6. Treat the pipeline as a product. Version it, review changes, give it an owner.

Choosing a CI/CD Platform

Testing Strategy: The Heart of Trust

CI/CD is only as trustworthy as its tests. Continuous deployment without good tests is just continuous breakage.

The Test Pyramid

Use the interactive test pyramid above to explore each layer. The key insight: invest heavily in fast, cheap unit tests as your base. Use integration tests to verify component interactions. Reserve expensive E2E tests for critical user journeys only.

Coverage: Use It Wisely

Coverage tells you what code is not tested, not whether tested code is well tested. Set a sensible floor (e.g., 80% on new code) and enforce it as a quality gate, but do not worship the number.

Shift-Left Quality Checks

• Linters and formatters (ESLint, Ruff, gofmt)
• Type checkers (TypeScript, mypy)
• Static analysis (SonarQube, CodeQL, Semgrep)
• Dependency vulnerability scans (Dependabot, Renovate, Trivy)
• Secret scanning (Gitleaks, TruffleHog)

Building & Packaging Artifacts

The Immutable Artifact

Your pipeline's most important output is an immutable, versioned, traceable artifact. Whatever you tested is exactly what you ship. Never rebuild for production.

Containerization with Docker

# ---------- Build stage ----------
FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build && npm prune --omit=dev

# ---------- Runtime stage ----------
FROM gcr.io/distroless/nodejs22-debian12:nonroot
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
ENV NODE_ENV=production
USER nonroot
CMD ["dist/server.js"]

Tagging & Versioning

Never deploy :latest. Tag with the git SHA for traceability (myapp:3f9c2ab), the semantic version for humans (myapp:1.8.2), and ideally deploy by digest (myapp@sha256:...).

Supply Chain Integrity

• SBOM — inventory every component (Syft, CycloneDX)
• Signing — sign images with Sigstore/cosign
• Provenance attestations — SLSA framework
• Dependency pinning — lockfiles, Renovate, allow-lists

Continuous Delivery & Deployment Strategies

Use the Deployment Strategy Visualizer above to see each strategy in action. Here's the theory behind them:

Environment Promotion

Artifact ─► Dev (auto) ─► Staging (auto + smoke/e2e) ─► [approval?] ─► Production

Same artifact, different configuration. Staging should mirror production as closely as practical.

Feature Flags — The Most Powerful Idea

Deploy code dark, then release by toggling flags per user, percentage or cohort. This decouples deployment from release — the single most powerful idea in modern delivery. Tools: LaunchDarkly, Unleash, Flagsmith, OpenFeature.

Database Migrations: The Hard Part

Use the expand/contract pattern: (1) Add the new column (backward-compatible), (2) Dual-write and backfill, (3) Switch reads, (4) Drop old column in a later release.

Infrastructure as Code & GitOps

Infrastructure as Code (IaC)

Servers clicked into existence in a console are unreproducible. Define infrastructure in code instead:

• Terraform / OpenTofu — declarative, multi-cloud
• Pulumi — infrastructure in TypeScript, Python, Go
• AWS CDK / CloudFormation / Azure Bicep
• Crossplane — cloud resources through K8s APIs

GitOps: Git as the Source of Truth

Developer ─► PR ─► CI builds image ─► CI updates image tag in config repo
                                                  │
                                      Argo CD detects change
                                                  │
                                    Syncs desired state to cluster

Why it's powerful: Complete audit history, cluster credentials never leave the cluster, disaster recovery is pointing a new cluster at the repo.

Secrets Management

Never commit secrets. Use secret managers (Vault, AWS Secrets Manager), External Secrets Operator for K8s, Sealed Secrets/SOPS for encrypted-in-Git workflows. Prefer short-lived, dynamically issued credentials.

Security, Observability & Governance (DevSecOps)

Security Belongs in the Pipeline

Observability: The Three Pillars

• Metrics (Prometheus, Datadog) — rates, errors, latency, saturation
• Logs (Loki, ELK) — structured, correlated by trace ID
• Traces (OpenTelemetry, Jaeger) — follow a request across services

Define SLIs/SLOs (e.g., 99.9% of requests succeed under 300ms). Wire automated rollback to SLO breaches.

Measuring, Scaling & a Roadmap to Mastery

Practical Adoption Roadmap

• Phase 1 (weeks 1–4): Everything in Git, protected main, PR reviews, automated build + unit tests + lint.
• Phase 2 (weeks 4–10): Containerize, publish versioned artifacts, add integration tests, get CI under 10 min.
• Phase 3 (months 3–5): Automated deploy to staging, IaC, secrets in a manager, practiced rollback.
• Phase 4 (months 5–8): Feature flags, canary deployments, SLOs, GitOps.
• Phase 5 (month 8+): Continuous deployment, policy as code, signed artifacts, SLSA, internal developer platform.

Common Anti-Patterns

Final Thoughts

CI/CD is not a tool you install. It is a discipline of small batches, fast feedback, automation and shared ownership. Start small: automate your build today, add tests this week, deploy to staging next month. Each step pays for itself.

1. Integrate early and often.
2. Automate everything repeatable.
3. Build once, promote everywhere.
4. Test at every level, and trust your tests.
5. Make deployment boring and release a business decision.
6. Observe, measure and learn from every change.