liveBook · Manning

Canary deployment

As explained in 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.

A canary deployment releases a change gradually to a limited subset of users before expanding it to the full population. Feedback and stability guide the rollout, making production changes safer. section 12.2.4

Use canary deployment as part of a broader deployment-safety practice:

  • Deploy in phases: move through early staging environments, pre-production, and production, allowing bake time between stages. section 12.2.4
  • Watch feedback and stability after the limited release before extending the change to more users. section 12.2.4
  • Consider feature flags separately when production features need controlled enablement, experimentation, or a kill switch. section 12.2.4

Limited release before full deployment

An engineering team releases a change to a subset of users, observes feedback and stability, and expands the deployment only when the results support doing so. section 12.2.4

How Think Like a Software Engineering Manager covers it

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.
How it connects
Connects phased deployments, staging environments, bake time, feature flags, and A/B testing.

Also explained in

Compare how 7 books explain canary deployment →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a Software Engineering Manager. The section links point to the parts of the book it draws on.