Canary deploy

A canary deploy is a release strategy in which a change goes to a small part of production first, is watched for a while, and is only rolled out further if it behaves. Google's SRE workbook defines canarying as "a partial and time-limited deployment of a change in a service and its evaluation" (Canarying releases).

What it is

The part of the service that gets the change is the canary. The rest, still on the old version, is the control. The rollout is an A/B comparison between the two: if the canary's metrics are worse than the control's, the change is stopped and rolled back.

The SRE workbook's advice on metrics:

• Start from your service level indicators (SLIs).
• Keep the set small; a dozen at most.
• Pick metrics that the change itself would move, not ones that shift for unrelated reasons, like overall CPU.
• Compare canary and control separately, since a service-wide number can hide the canary's errors.

Why it matters

Tests can't cover everything real traffic does. A canary limits a bad change to a small share of users for a short time, which turns many would-be incidents into a quiet rollback.

In AI CodeOps

AI CodeOps doesn't run canaries; your pipeline does the rollout. Its deploy gates work at the environment level: a policy rule can deny deploys to an environment, and the release check from CI can require a succeeded staging deployment before a change goes to production.