Shipping: CI/CD, Supply Chain and Infrastructure

Sign in to save your progress across devices. Until then it is kept in this browser.

Why this matters

AI lets you write ten times more change. Without an automated, safe path to production, that becomes ten times more incidents. DORA's research is clear that speed and stability are not trade-offs: the best teams deploy often and fail less, because each change is small, tested and reversible.

Learning outcomes

1. Build a CI/CD pipeline with quality and security gates.
2. Containerise reproducibly with Docker.
3. Secure the software supply chain (lockfiles, SBOM, provenance, slopsquatting).
4. Release progressively with feature flags, rolling, canary and blue-green.
5. Roll back in under a minute.
6. Define infrastructure as code.
7. Know when (and when not) to use Kubernetes.

Lessons

11.1 The pipeline (6, 107)

On every pull request: install (from lockfile) → lint → type-check → unit tests → integration tests (real DB in a container) → security scans (secrets, SAST, dependencies) → build → preview deploy → E2E tests on preview. On merge to main: build once, deploy the same artifact to staging then production, run migrations as a controlled step, smoke test, monitor.

• Branch protection: required reviews and passing checks; nobody (and no agent) pushes to main directly.
• Build caching (107) keeps CI fast (dependency and layer caches, remote caches in monorepos). Slow CI makes people skip it.

11.2 Docker (7)

• Multi-stage builds; small base images (distroless, alpine, or slim); pin image digests.
• Run as non-root; no secrets in images or layers; .dockerignore.
• Scan images (Trivy) in CI. Same image runs locally, in CI and in production: the end of "works on my machine."

11.3 Supply chain and dependency hell (108, OWASP A03:2025)

• Lockfiles committed; npm ci / frozen installs in CI.
• Slopsquatting: AI tools sometimes suggest packages that do not exist; attackers register those names. Verify every new dependency exists, is maintained, has real usage, and is spelled right.
• Automated updates (Dependabot/Renovate) with tests; group minor updates; review majors.
• Minimise dependencies; prefer the platform and standard library.
• SBOM (CycloneDX or SPDX) generated per build; provenance/signing (SLSA framework, Sigstore/cosign, GitHub artifact attestations). Enterprise customers increasingly ask for SBOMs.
• Pin GitHub Actions to commit SHAs; least-privilege GITHUB_TOKEN permissions.

11.4 Progressive delivery (51 to 55)

• Feature flags (51): deploy code dark, release to internal users, then a %, then all. Separate deploy from release. Clean up old flags (they are tech debt).
• Rolling (54): replace instances gradually; default on most platforms.
• Canary (53): send a small % of traffic to the new version, compare error rate and latency, auto-promote or abort.
• Blue-green (52): two full environments; switch traffic instantly; instant switch back.
• Rollback (55): the most important one. Platform instant rollback (Vercel, Cloudflare, Fly, Render) or redeploy previous image tag. Practise it. Database migrations must be backward compatible so code rollback is safe (03 · Data Foundations expand and contract).

11.5 Infrastructure as code (104, 105)

• Everything (DNS, buckets, DBs, queues, IAM, alerts) defined in code, reviewed in PRs, applied by CI. No click-ops in production.
• Terraform / OpenTofu (105), Pulumi (TypeScript), or platform config files. State stored remotely and locked.
• Benefits: reproducible environments, audit trail, disaster recovery by re-apply.
• Scan IaC for misconfig (Checkov, Trivy).

11.6 Kubernetes, Helm, service discovery (8, 9, 106)

• Kubernetes (8) orchestrates containers: scheduling, self-healing, scaling, rolling updates. Helm (106) packages K8s apps. Service discovery (9) lets services find each other by name.
• Honest guidance: for a small team, a managed PaaS (Vercel, Cloudflare, Fly, Render, Railway, Cloud Run, ECS) gives most of the benefit at a fraction of the operational load. Adopt K8s when you have many services, a platform team, or enterprise/on-prem requirements.

11.7 Environments

Local → preview (per PR) → staging (production-like, anonymised data) → production. Separate credentials and accounts per environment. AI agents never hold production credentials by default.

Lab 11: Ship ten times in a day

1. Build the full pipeline above in GitHub Actions.
2. Add SBOM generation and dependency + container scanning; fail on criticals.
3. Wrap a new feature in a flag; release to 10% then 100%.
4. Ship a deliberate bad deploy; detect and roll back. Time it.
5. Define your infra (at least DNS, DB, storage, one alert) in Terraform/OpenTofu or Pulumi.

Definition of Done

• Main branch protected; all changes through PR + passing CIEvidence
• Security scans and SBOM in pipelineEvidence
• Actions pinned to SHAs; dependency update bot activeEvidence
• Feature flag system in useEvidence
• Rollback measured at under 1 minute (evidence: timestamps)Evidence
• Core infrastructure in codeEvidence
• Deployment frequency and change fail rate tracked (DORA)Evidence

AI prompt pack

• "Write a GitHub Actions workflow with lint, typecheck, tests with a Postgres service container, gitleaks, Semgrep, dependency audit, Docker build with Trivy scan, and SBOM. Pin all actions by SHA and use least-privilege permissions."
• "For every dependency added in this diff, confirm it exists on the registry, its weekly downloads, last publish date, and maintainer count."