Concept and mechanism
A controlled release connects the artifact to evidence, approval, and outcome observation. A canary exposes a traffic fraction to allow comparison before expanding impact. Define version-specific signals, advancement criteria, and stop conditions. A global average can dilute a failure affecting 5% of traffic. Binary or routing rollback does not automatically restore data. If a release removes a column or writes an incompatible format, the previous version might stop working even after the image is restored. Plan compatibility, migration sequence, and persistent-state recovery. Depending on evidence, an approved forward fix can be less risky than attempting data conversion during an incident.
Guided application
In a fictional cutover, the initial database copy does not demonstrate final synchronization while the source keeps receiving writes. Confirm the delta, write control, reconciliation, and acceptance criteria. Review IaC plans before applying replacement of resources containing data: versioned code does not automatically recover destroyed state. For APIs, treat incompatible changes as consumer contract changes and track adoption before retiring versions. Unit tests and emulators accelerate feedback but do not demonstrate every production IAM control, quota, or private path. Add integration tests in a representative environment and retain evidence. The aim is an informed delivery and recovery decision with owners able to execute the procedure.
A canary can contain real transactions; 5% traffic does not mean disposable data.
Common pitfalls
Green deployment as correct outcome; image rollback as data restoration; emulator as production.
Related topics: Requirements, costs, and platform selection · Data, resilience, and events · Networking, provisioning, and capacity
Validate artifact, path, state, and criteria before expanding the release.
Reference: Cloud Deploy canary strategy · Current linked standard guide; edition date unconfirmed (2026-09-30 inspection)