CI/CD pipelines automate the path from source change to production. Continuous integration checks that a change can be merged safely. Continuous delivery keeps the software always releasable. Continuous deployment ships successful changes automatically.
A good pipeline is fast enough to use on every change, deterministic enough to trust, and visible enough that failure has an obvious owner.
Pipeline shape
flowchart LR Commit["Commit"] --> Build["Build artifact"] Build --> Test["Test"] Test --> Scan["Security and quality checks"] Scan --> Package["Package"] Package --> Staging["Deploy to staging"] Staging --> Smoke["Smoke test"] Smoke --> Production["Promote to production"] Production --> Verify["Verify and observe"]
The same artifact should move through environments. Rebuilding for production after testing a different artifact weakens the evidence the pipeline produced.
Core practices
- Keep branches short-lived so integration happens while context is fresh.
- Parallelize independent checks and cache dependencies.
- Fail early on cheap checks, then run slower integration and end-to-end tests.
- Promote artifacts, not source.
- Gate production with the smallest checks that catch real risk.
- Make rollback or roll-forward a practiced path, not a custom incident response.
Deployment strategies
| Strategy | How it works | Best fit |
|---|---|---|
| Rolling deploy | Replace instances gradually | Stateless services with simple health checks |
| Blue-green | Shift traffic between two complete environments | Fast rollback when duplicate capacity is affordable |
| Canary | Send a small percentage of traffic to the new version | Risky changes with strong monitoring |
| Feature flag | Deploy code separately from exposure | Product experiments and staged rollout |
Deployment strategy is part of the pipeline design. It determines what evidence is needed before and after release.
What to measure
- Lead time from merge to production.
- Build duration and queue time.
- Failure rate by stage.
- Mean time to recover from a bad deploy.
- Flaky test rate.
- Frequency of manual overrides.
The point is not to optimize pipeline metrics in isolation. The point is to shorten feedback while keeping production change controlled.
Common failure modes
Pipelines become weak when they hide too much manual work outside version control, depend on shared mutable environments, require tribal knowledge to recover, or accumulate slow checks that nobody trusts. Infrastructure as code helps by making environments reviewable and repeatable.