Release, Deployment, and Incident Management
What this domain tests
Release, Deployment, and Incident Management tests safe change strategies and incident response: deployment versus release, blue-green, canary, rolling updates, rollback, severity, on-call, and blameless postmortems.
Core rules and concepts
- Deployment puts code into an environment; release exposes it to users. Feature flags let you deploy without releasing.
- Blue-green runs two environments and switches traffic, giving fast rollback but doubling infrastructure during cutover.
- Canary sends a small percentage of traffic to the new version, watches error rate and latency, then ramps. Automated rollback is the point.
- Rolling updates replace instances gradually; they require readiness probes and correct surge and unavailable settings.
- Incident management: declare severity early, assign an incident commander and a communications lead, and keep a timeline. Mitigate first, root-cause later.
- Blameless postmortems document contributing factors, detection gaps, and action items with owners and dates.
Worked example
A canary at 5% shows a 2% error rate versus a 0.2% baseline. Reasoning: the canary has done its job. Do not ramp to 25% because it might settle. Compare against the baseline with enough sample size, then automatically roll back, preserve logs and traces, and investigate. If traffic is too low to detect a 1% regression quickly, lengthen the canary or use synthetic checks rather than skipping the gate.
Traps that cost marks
- Confusing deployment with release, then claiming we released when the flag is off.
- Having no tested rollback path, especially for database migrations.
- Blaming an engineer in a postmortem and calling it human error.
- Skipping stakeholder communication during customer-impacting incidents.
- Ramping a canary without a defined success threshold and automated abort.