A CI/CD pipeline is the automated path code travels from a developer’s commit to production. When it is fast and trustworthy, teams ship small changes often. When it is slow or flaky, releases get bigger, riskier and rarer.
Continuous integration
Every push triggers the same automated checks, so problems are caught minutes after they are introduced rather than days later.
- Install dependencies from a lockfile for reproducible builds
- Lint and type-check
- Run unit tests
- Build the application artefact once
Continuous delivery and deployment
Build once, promote everywhere
The same artefact that passed tests should move through staging to production. Rebuilding per environment invites “it worked in staging” surprises.
Environment configuration
Keep configuration and secrets outside the artefact, injected per environment by the platform or a secrets manager — never committed to the repository.
Safe release strategies
- Blue-green: run two identical environments and switch traffic in one step.
- Canary: send a small share of traffic to the new version and watch error rates.
- Feature flags: deploy code dark and enable it separately from the deploy itself.
Keep the pipeline fast
Cache dependencies, run independent jobs in parallel and move slow end-to-end tests to a later stage. A pipeline developers wait on for a long time is a pipeline they will try to bypass.
Make rollback boring
Every release should be reversible with one command or one click. Practise it. Database migrations deserve special care: prefer backwards-compatible, additive changes that let the previous version keep running.
Quick answers
Is continuous deployment required?
No. Continuous delivery means every change is releasable; a person can still press the final button. Many teams start there and automate the last step later.
What should block a merge?
Anything that indicates broken behaviour: failing tests, type errors, a failed build. Style-only issues are better fixed automatically than used as blockers.
- CI/CD
- DevOps
- Testing
