A good pipeline gives developers fast feedback and ships changes safely. Here's how we think about designing them.
Fast Feedback First
Run the quickest checks first: lint, type checks, unit tests. Fail fast so developers see problems within minutes. Parallelize jobs where possible and use caching for dependencies and build artifacts. A pipeline that takes 20 minutes will be bypassed or ignored; aim for under 10 for the main branch.
Stages That Match Your Risk
Typical stages: build → test → staging deploy → production deploy. Add gates: require tests to pass, optional manual approval for production, and run integration or E2E tests in staging. Don't deploy to prod on every commit unless you have feature flags and a culture that supports it.
Reproducibility and Rollback
Build once, deploy the same artifact everywhere. Tag images and releases. Have a one-click (or one-command) rollback so you can revert without re-running the whole pipeline. Document the process so anyone can ship or roll back when needed.
Security in the Pipeline
Scan dependencies and images for known vulnerabilities. Run SAST (static analysis) on code. Keep secrets out of logs and use a secret manager. A pipeline that catches a critical CVE before deploy is worth the extra few minutes.