Deployment & rollout
Deployment provides an artifact in a runtime environment. A rollout controls how instances or traffic change from the previous version to the new version.
- CanaryA small share of traffic first.
- CriterionPre-determined limit.
- Return pathThe previous version is still activated.
Context
Why this is important
If a new version is rolled out for everyone at once, an error immediately hits all customers. A stepped rollout limits the effect and requires a way back. Data migration and recovery deepen your own building blocks.
This building block deals with deployment and traffic change. Data migration plans compatible schema changes; recovery handles returns after data or system loss.
At a glance · Step-by-step switching between versions
Canary rollout of the tax rule
The shop publishes a new tax rule initially for a small share of traffic. Old and new versions read the same additive database schema during the rollout.
This is how you read the picture
- Canary Stages 1%, 5%, 25% and 100% for 'new version traffic share'.
- Criterion Stage hints require checking error rate and latency before proceeding.
- Return path For 'New tax rule miscalculates', the hint recommends rolling back.
- New version traffic share
- 1 %
- affected orders per hour
- 0 of 400
Very small share: check the signals before more traffic goes to the new version.
Quantities illustrative
Benefits & limitations
Helps if:
- Running services need reproducible, observable version transitions for regular updates.
- Staged releases connect changes to agreed measurement criteria for user experience.
Boundaries
- Business success indicators and representative workflows complement process and readiness checks before each further release stage.
- Incompatible data changes can prevent rollback; introduce additive schema changes and test the return path.
- Without per-version measurements, a canary runs blind; base stop rules on Observability and SLO targets.
In practice
- Map the artefact to its environment. Version the tested package and record its configuration and target environment. Use the same artefact at every release stage. This clearly links the source revision, validation and deployed version.
- Set release criteria. Define readiness, minimum capacity, observation duration and failure or response-time thresholds. Decide in advance who triggers expansion or stopping. This makes traffic admission depend on testable conditions.
- Test coexistence and rollback. Test contracts and data with versions running concurrently, and define how in-flight requests drain during shutdown. Check that the previous version can still run after the changes. This establishes a reliable rollback path.
Read the detailed explanation
Deployment places a tested artefact in a target environment; rollout describes the transition of instances or traffic. Rolling updates replace instances gradually; canary strategies release to a small share. Readiness, capacity and graceful shutdown safeguard the transition. Versioned artefacts and data compatibility connect rollout to Data migration and Recovery.
Old and new versions may run concurrently and must understand shared contracts. Application rollback requires earlier versions to remain able to read the data left behind. Release stages compare defined operational indicators and user signals. A successful process start alone confirms neither business success nor data compatibility, so rollout needs criteria for expansion, stopping and rollback.
Blue-green deployment maintains two complete environments and switches traffic to the new one; a canary release initially gives the new version only a small share.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
How many orders per hour are affected by the defect at 5%?
View the solution with justification
20 of 400 orders per hour (illustrative).
ApplyingTransferred to a new situation
At 5% the error rate rises above the threshold. What do you do?
View the solution with justification
Stop the rollout and roll back to the previous version. The share is not increased.
EvaluateWeighing an alternative
The team rolls out directly at 100%. What speaks for it, what speaks against it, and what do you recommend?
View the solution with justification
Advantage: faster, only one version. Disadvantage: a defect immediately affects all 400 orders per hour. Recommendation: start with 1% or 5%, check the signals, then increase in stages.
Explore further
These optional deepenings complement the learning goal of this page.
Serverless execution
With serverless, the platform provisions and scales runtime resources for functions or managed services. Stateful workflows and data belong in external stores designed for them. Execution duration, cold-start latency, concurrency and platform limits shape the design; the team retains responsibility for operations and architecture.
In the shop, asynchronous invoice generation can run as a function while request status and the resulting file are stored externally. Long-running executions or requirements for local state may call for a different runtime.
For testingPlan asynchronous invoice generation in the shop as a serverless function: store request status and the resulting file externally, define execution and retry limits, and test cold-start latency and concurrency limits. Also identify which platform limit requires a different execution model for long-running invoice jobs or required local state.
Further building blocks
References
- Kubernetes – Deployments (opens in new tab)Describes rolling updates, rollbacks, and progress control.
- Martin Fowler – Blue Green Deployment (opens in new tab)Explains switching and relapse between two deployment environments.
- Google SRE Workbook – Canarying Releases (opens in new tab)Shows step-by-step release and evaluation of Canary signals.
- Microsoft · Leveraging serverless functions (opens in new tab)Execution model, tasks and start latency of serverless functions.