Designing a CI/CD pipeline that people trust

What stages should a pipeline have?

Run independent stages in parallel. Lint, type check and unit tests have no reason to be sequential, and parallelising them typically halves the wall-clock time of a pull request check.

Why build once and promote?

Because rebuilding per environment means the artifact you tested is not the artifact you shipped.

Build a single immutable image tagged by commit SHA, push it once, and deploy that exact digest to staging and then production. Configuration comes from the environment at runtime. If staging passed and production fails, you have eliminated 'the build was different' from the investigation.

- name: Build and push
  run: |
    docker build -t $REGISTRY/app:$GITHUB_SHA .
    docker push $REGISTRY/app:$GITHUB_SHA

- name: Deploy to staging
  run: ./deploy.sh staging $REGISTRY/app:$GITHUB_SHA

- name: Deploy to production      # same digest, different config
  if: github.ref == 'refs/heads/main'
  run: ./deploy.sh production $REGISTRY/app:$GITHUB_SHA

How do you keep pipelines fast?

1. 1Cache dependencies keyed on the lockfile hash — the single biggest win in most pipelines.
2. 2Cache build outputs where the tooling supports it (Next.js build cache, Turborepo, Nx).
3. 3Run only what changed in a monorepo, using path filters or a task graph.
4. 4Shard test suites across parallel runners.
5. 5Move slow, non-blocking checks off the critical path and report them asynchronously.
6. 6Measure pipeline duration over time and treat regressions as bugs.

What should environments look like?

• Preview per pull request, with its own URL and seeded data — the highest-value environment you can offer reviewers.
• Staging that mirrors production configuration, with production-like data volumes where possible.
• Production, deployed from main only, with an approval gate if your risk profile needs one.
• Separate credentials and databases per environment, always.
• Staging blocked from search engine indexing via an environment variable, not a code branch.

What about rollbacks and secrets?

1. 1Rollback must be a single command redeploying the previous digest — and it must have been rehearsed.
2. 2Keep database migrations backwards compatible so a code rollback does not require a schema rollback.
3. 3Secrets come from the platform's secret store, injected at runtime, never committed and never in build args.
4. 4Deployment credentials use short-lived identity federation rather than long-lived static keys.
5. 5Every deployment is recorded: who, what commit, when — this is the first thing you check during an incident.