We designed a progressive deployment policy to reduce customer impact from releases. Changes go to a subset first and are checked before the rollout expands to the entire service.
We did not apply the same policy to every role. We distinguished roles by their function within the service and made progressive deployment mandatory only for key roles that could directly affect customers.
Increasing adoption alone would not reduce customer impact. Detecting problems during the partial rollout makes it possible to respond before expanding to the entire service.
We reviewed past deployment incidents and asked whether progressive deployment could have reduced their impact. We replayed deployment history with request rate, error rate, and duration (RED) metrics to test detection thresholds.
We asked teams why they did not use progressive deployment. Some worried about false automatic rollbacks. Others did not know whether a deployment stopped during the partial rollout would count as an incident. Some teams were unfamiliar with the policy itself.
We needed to address these problems before presenting a standard.
Enabling progressive deployment does not mean that a policy is followed. We measured the share of deployments using it separately from the share of mandatory targets meeting the standard.
Adoption measured how many deployments enabled progressive deployment. Compliance checked whether mandatory targets followed the agreed procedure. A gap between them helped us find a product limitation or a policy exception.
We separated the two measures to find where users stopped in the process.
Google SRE also describes exposing a change to part of the traffic and evaluating it before deciding whether to continue. Release automation reduces repetitive work and creates a consistent process. Canarying Releases
After the policy was applied, the number of rollbacks following a full rollout fell noticeably. Assessing the policy requires checking that reduction alongside adoption and compliance.