A deployment approach that sends a new software version to a small share of users first, then expands it if no problems appear.
The name comes from the canaries miners once used to detect dangerous gas. In a canary release, most users stay on the current version while a small group, perhaps one or five percent, receives the new version. Teams watch error rates, response times, and business metrics. If the canary performs well, the rollout gradually expands to everyone. If not, it is rolled back.
For example, a ride-hailing app might release a redesigned payment screen to two percent of users in one city and compare completed payments with the existing version before a wider launch. Canary releases limit the impact of bugs that tests missed. They require good monitoring and traffic routing tools, and they work well alongside feature flags.
A release method that runs two identical production environments and switches traffic from the old one to the new one once it is ready.
Feature FlagA switch in software that turns a feature on or off for some or all users without deploying new code.
ObservabilityThe ability to understand what is happening inside a software system by examining the data it produces, such as logs, metrics, and traces.
DevOps sets the goals, SRE supplies a concrete playbook for reliability. Here is how their goals, metrics and team structures differ and how to run both without turf wars.
SRE turns reliability into numbers teams can manage. Here is how error budgets and toil limits work, how SRE relates to DevOps, and how to apply it outside big tech.
What shift-left testing means, why teams move tests earlier, and the practical changes it asks of developers, testers and pipelines.