Progressive delivery
Keep the stable release compatible with canary writes
A small rollout still changes shared data. Separate incompatible schema and behaviour changes so the stable application remains a usable recovery path.
In this article
List what the candidate can write
Include database fields, event formats, cached values and external effects. The canary may share all of them with the stable release even when it receives little traffic.
For an illustrative status change, the candidate might write awaiting-review while the stable code recognises only pending and complete. Returning traffic to stable can then fail on records created during the trial.
Resolve that compatibility before enabling exposure. A traffic percentage does not reduce the meaning of an unsupported stored value.
Expand readers before new writes
Where appropriate, deploy support for the new representation while keeping existing behaviour. Verify that both old and new data can be read under the supported release sequence.
Then introduce the candidate's new writes behind a controlled exposure rule. Keep the database migration and feature activation as separate observable steps.
If compatibility cannot be maintained, define a different recovery strategy and state its consequences. Do not present ordinary traffic rollback as available when it is not.
Exercise the reverse traffic path
Write representative data through the candidate, abort the rollout and continue the workflow through stable. Include background consumers and cached representations.
Test unknown outcomes and duplicate requests across versions. Both releases need a coherent interpretation of operation identity where they share the same business effect.
Inspect the stored result independently so a friendly error page does not conceal a damaged record.
Remove compatibility later
After promotion and the required recovery window, identify consumers that still need the old representation. Scheduled jobs and retained events may extend that period.
Remove old fields and fallback paths in a separate reviewed change when their dependencies are gone. This makes the irreversible boundary visible.
Keep the rollout record clear about which builds remain safe to deploy. A list of available container images is not enough to establish that each one can operate on today's data.
Primary sources
Argo Rollouts: canary deploymentsReferences checked 11 September 2026.