liveBook · Manning

Canary deployment

A canary deployment is a release strategy that exposes a change to a limited portion of users, traffic, or infrastructure before expanding it more broadly.

How 7 Manning books explain it

Platform Engineering on Kubernetes

A canary release is a deployment technique that gradually routes live traffic to a new software version while retaining traffic on a stable version for early validation and rollback.

How it is used
Reduces release risk by validating a new service version against a controlled share of live traffic before full promotion.
How deep it goes
Works through replica-based splitting, Knative revision rules, and Argo Rollouts steps; defers detailed Istio configuration.
Examples
Uses a notifications service, 50/50 Knative revision routing, curl responses from two versions, and a staged Argo Rollout.
What you can do after
Apply it via Knative Service traffic rules or Argo Rollouts steps, then validate, promote, or redirect traffic to the stable version.

Read how Platform Engineering on Kubernetes explains canary deployment →

Kubernetes in Action, Second Edition

A release technique that exposes a new application version to a limited subset of instances or traffic before expanding it broadly.

How it is used
Limits exposure to a new application version while its behavior is checked before a wider rollout.
How deep it goes
Explains two-Deployment traffic distribution and manual rollout controls, but gives no automated approval procedure.
Examples
Uses stable and canary pods, rollout pause and resume commands, and a three-replica StatefulSet partitioned to update one pod.
What you can do after
Practice/perform a limited rollout using separate Deployments, a paused Deployment update, or a StatefulSet partition.

Read how Kubernetes in Action, Second Edition explains canary deployment →

Infrastructure as Code, Patterns and Practices: With examples in Python and Terraform

A canary deployment is a release pattern that incrementally exposes a change to a limited portion of users, traffic, or infrastructure before expanding it broadly.

How it is used
Deploys significant infrastructure changes gradually to detect failures before they affect all requests.
How deep it goes
Explains traffic weighting, rollback, monitoring, regression windows, and stateful cutover, but leaves increment selection context-dependent.
Examples
Uses blue-green networks, weighted load-balancer services, application instances, and staged database writes and reads.
What you can do after
Operate/configure incremental traffic shifts, monitor regressions, and revert to the previous environment when failures emerge.

Read how Infrastructure as Code, Patterns and Practices: With examples in Python and Terraform explains canary deployment →

Machine Learning System Design

Canary deployment is a release strategy that sends a limited portion of users or traffic to a new version before fully switching over.

How it is used
Controls production risk by testing a release with a small user portion before completing the switch.
How deep it goes
Defines concurrent versions, granular routing, rollback, and A/B-test distinction without detailing rollout controls or evaluation metrics.
Examples
Uses a search system that releases ranking models separately from its index, filter, and API layers.
What you can do after
Operate/configure staged production releases with fallback versions and independently deployed ML components.

Read how Machine Learning System Design explains canary deployment →

Google Anthos in Action

A canary deployment is a release strategy that exposes a new version to a small portion of traffic before expanding its availability.

How it is used
Supports safer microservice releases by testing new versions with limited production traffic before broad rollout.
How deep it goes
Explains rollout stages, concurrent versions, percentage and user-agent routing, but does not detail deployment configuration.
Examples
Uses a 5% traffic split and user-agent targeting for Service A through Istio.
What you can do after
Operate progressive releases by routing selected traffic to a new version and expanding exposure after testing.

Read how Google Anthos in Action explains canary deployment →

Think Like a Software Engineering Manager

A canary deployment releases a software change to a limited subset of users or infrastructure before expanding it to the full population.

How it is used
Improves production safety by releasing changes gradually to a subset of users before full deployment.
How deep it goes
Defines gradual release and feedback-based expansion, but does not detail rollout mechanics or measurement.
Examples
Uses subset releases alongside alpha, beta, pre-production, and production deployment stages.
What you can do after
Apply it via gradual production rollout, using feedback and stability to guide expansion.

Read how Think Like a Software Engineering Manager explains canary deployment →

Kubernetes for Developers

A rollout is the controlled propagation of an application or platform update across its deployed instances or locations.

How it is used
Uses limited traffic exposure to validate an application version before completing a production cutover.
How deep it goes
Describes staged users, traffic percentages, validation, and decisions, but stops short of defining detailed analysis criteria.
Examples
Uses internal users followed by a percentage of external production traffic before full cutover.
What you can do after
Apply it via Istio and Spinnaker to split traffic and automate deployment decisions.

Read how Kubernetes for Developers explains canary deployment →

Related concepts

These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.