A good CI/CD pipeline is invisible. A bad one is a daily source of friction, flaky tests, and the "it works on my machine" problem. Here's what we set up from day one on every project.
Pipeline structure
Every push to any branch runs: lint → type check → unit tests. Every PR to main adds: integration tests → build → preview deployment. Every merge to main: full test suite → build → staging deployment. Every tag: production deployment with manual approval gate.
Speed is a feature
A CI pipeline that takes 20 minutes kills developer flow. We target under 5 minutes for the PR pipeline. Key optimisations:
- Layer caching for Docker builds — cache the dependency install layer separately from the application code
- Test parallelisation — split the test suite across multiple runners
- Incremental type checking — only check changed files on PRs
- Smart test selection — run only tests related to changed files for the fast path
Preview deployments
Every PR gets a preview deployment with a unique URL. This is non-negotiable. The ability to share a live URL for review — with designers, product managers, and clients — eliminates an entire category of miscommunication.
Secret management
Secrets never live in the repository. We use GitHub Actions secrets for CI, and environment-specific secret stores (AWS Secrets Manager, Doppler, Vault) for runtime. Every new engineer gets onboarded to the secret store on day one.
Rollback is a one-command operation
Every deployment should be reversible in under 2 minutes. We use immutable deployment artifacts (Docker images tagged with git SHA) and maintain the last 5 production builds for instant rollback. The rollback command is documented in the README.