A smaller rollout is an experiment with an acceptance decision
A canary exposes a candidate to a controlled portion of a rollout before wider adoption. The useful result is evidence about application behavior, not merely a completed deployment command. Define what the team must learn during a phase and what would prevent promotion before the first candidate is introduced.
Cloud Deploy supports canary phases and verification options for supported target and networking designs. Google documents differences between automated and custom configurations. Select the design that matches the target rather than assuming a traffic percentage has identical meaning for every deployment environment.
Prepare the experiment
- Record the candidate artifact, target, previous accepted release and application changes. Review database, message and API compatibility between old and new versions.
- Define phase observations such as successful user transactions, latency, errors and relevant business outcomes. Include enough representative work to make the observation meaningful.
- Set promotion authority, stop conditions and recovery steps. Rehearse a deliberately failing candidate and verify who can halt expansion.
For beginners, traffic division does not guarantee that the sample contains every customer workflow. A rare administrative or billing operation may receive no useful coverage during a short quiet phase. Keep targeted acceptance tests alongside passive observation.
Illustrative incident: health passes, one workflow regresses
A candidate starts successfully and serves its health endpoint, but a business form rejects valid submissions. The canary phase remains technically deployed while the affected workflow fails. This is an illustrative scenario. Promoting because the infrastructure status is green would expand the application regression.
Compare candidate and accepted behavior fairly
Link observations to the actual candidate version and phase. Account for request mix, observation duration and normal baseline variation. If the sample is too small, record insufficient evidence instead of calling the absence of errors a proven success.
| Observation | Evidence | Promotion decision |
|---|---|---|
| Candidate is healthy but a fixture fails | Business-operation result | Stop for application review |
| Few or no representative requests | Sample volume and workflow coverage | Extend or supplement testing |
| Candidate metrics differ from baseline | Version-scoped errors and latency | Investigate regression |
| Recovery cannot restore compatibility | Schema and side-effect history | Escalate release risk |
Avoid using a single aggregated dashboard that mixes candidate and stable traffic without identification. A small failing candidate can disappear inside a large healthy total. Preserve the version and phase context in the release evidence.
Recover within the application's compatibility boundary
For the illustrative form failure, stop expansion and use the reviewed target-specific recovery process. Verify that traffic and business operations return to the accepted behavior. If the candidate has already made incompatible data changes, treat reversal as a separate engineering decision rather than assuming a traffic switch restores every effect.
Correct the candidate, rerun the targeted fixture and begin a new evidence-based rollout. Demonstrate a failed verification path and a successful recovery rehearsal outside production. Keep the precise accepted artifact rather than rebuilding an older release from an unpinned dependency set.
Reliability objective and canary SOP
Measure release-attributable transaction failures and time to halt a bad candidate. An illustrative internal gate could require representative business fixtures and a defined observation window before each promotion. It is a release rule, not a Cloud Deploy SLA or a universal zero-downtime guarantee.
The SOP should retain release, target design, phases, fixtures, sample evidence, approver and reversal boundary. Escalate uncertain compatibility before deploying the canary. Review the observation plan when a release changes user workflows so the rollout tests the risk actually introduced by that candidate.
See Clouvenix engineering support for scope based on documented requirements and acceptance evidence.
Technical reference
Google Cloud: canary deployment strategy. Reviewed 19 October 2026; check prerequisites against the product configuration and software version in use.