Release Ring
An ordered cohort of users a change reaches before the next one, chosen so that early rings would notice a fault and tolerate it.
Rings generalise canarying from "some traffic" to "some people, deliberately chosen". Ring zero is the team itself, ring one is internal staff, ring two is customers who opted into early access or whose accounts are low-risk, and the outer rings are everyone else. A change dwells in each ring long enough for its failure mode to appear before advancing.
The choice of cohort matters more than the percentage. A five percent random canary held for fifteen minutes will not surface a fault that only manifests in end-of-month billing runs or only for accounts with a particular configuration. Rings let you put the users most able to report a problem, and least harmed by one, in front of it first.
The cost is that a change exists in several versions simultaneously, so both the data schema and any shared service contract must tolerate all of them at once. That constraint is the real work of progressive delivery; the traffic-splitting mechanism is the easy part.