Continuous Deployment and Delivery
This domain, continuous deployment and delivery, tests how testing fits a pipeline that keeps software releasable. Expect questions on CI, deployment pipelines, quality gates, environments and data, release patterns, monitoring and rollback.
Core rules
- Continuous integration means integrating to trunk frequently with an automated build and fast unit/component tests.
- Continuous delivery keeps every change deployable to production; release is a business decision. Continuous deployment automatically sends every passing change to production. The two are not synonyms.
- A deployment pipeline typically runs commit build → static analysis → unit → integration/API → acceptance → non-functional subset → staging → production, failing fast and applying risk-based gates.
- Environments and data should be production-like, reproducible through infrastructure as code, with ephemeral environments and masked or synthetic data.
- Release patterns: blue-green switches traffic between identical environments; canary sends a small percentage first; feature flags decouple deploy from release; dark launches and A/B tests limit exposure.
- Monitoring and observability (logs, metrics, traces, synthetic checks) provide production feedback; define rollback or roll-forward before release.
Worked example
A team wants daily releases. Reasoning: pull requests trigger unit tests and static analysis under ten minutes; merges run build, API contract tests and acceptance smoke; staging runs a non-functional subset; a 5% canary runs for 30 minutes with an error-rate gate before full rollout. An incomplete feature sits behind a flag, and blue-green switching provides rollback. Each gate is tied to a risk rather than added by habit.
Traps
Equating continuous delivery with continuous deployment; leaving all testing until after deployment; long UI regression in the commit stage; one shared staging environment causing queues; canary releases without monitoring; no database migration or rollback plan.