Canary deployment
A canary deployment initially gives a new version limited traffic. Observed outcomes determine whether expansion continues or stops.
A canary deployment initially sends a new application version only a limited share of traffic or a selected user group. The team observes defined outcomes before expanding usage.
A hypothetical portal checks whether orders are correctly confirmed and whether errors increase at this stage. Continue and stop criteria are defined beforehand. Sending only a few requests to the new version without assessing outcomes would not provide this learning step.
The selected group does not automatically represent every product or customer situation. Errors can also become visible later. Old and new versions must remain compatible with shared data. Canary checks can be combined with other deployment strategies; they do not guarantee an error-free launch.
Sources
Related terms
- Blue-green deploymentBlue-green deployment prepares a new version in a second environment. After checks, traffic switches from the current environment to the new one.
- Rolling updateA rolling update replaces running application instances gradually. Old and new versions may work simultaneously during the transition.
- MonitoringMonitoring continuously collects and evaluates selected system states and functions. What it tells you depends on what is actually observed.
- Return-PathReturn-Path records the SMTP reverse path in a header. It explains the technical route for error reports, not a person’s identity.
- Envelope-FromEnvelope-From identifies the SMTP sender for transport and error feedback. It must be distinguished from the visible sender address.
- DMARC aggregate reportA DMARC aggregate report summarises a reporting mail system’s domain checks over a period. It helps examine sending sources and misconfigurations.
Articles on this topic
Cloud & Operations with ASES
Hosting, deployment, maintenance and support