Workflows
Canary Release Workflow
Validate new versions on a small slice of real production traffic before broad rollout to reduce blast radius.
- Teams turning commands into repeatable routines
- Readers who need sequencing, branch, and sync discipline
- Basic understanding of fetch, pull, push, and branches
- A sense of how and why branches diverge
- Copying a workflow without checking branch state
- Choosing the wrong integration path on shared branches
Canary releases let a small percentage of real users validate a new version before full rollout.
Best-fit scenarios
- high-impact paths where full rollout is risky
- environments with traffic splitting and real-time observability
- releases requiring production-behavior verification
Recommended sequence
1. Define pass/fail thresholds
Include error rate, latency, and business KPI bounds.
2. Deploy initial canary slice
Start with 1% traffic or one zone/cluster.
3. Observe for a fixed window
Do not promote immediately after deployment.
4. Promote in stages
1% → 5% → 20% → 50% → 100%, re-evaluating each stage.
5. Stop or rollback on threshold breach
Pause promotion first; then rollback version or disable risky features if required.
Teams need clear rules for promotion and rollback. Otherwise canary cannot act as a safety mechanism.
Common mistakes
Mistake 1: tracking only technical signals
Business-path degradation can be missed if only system metrics are observed.
Mistake 2: too-short observation windows
Some issues surface only under peak traffic or delayed jobs.
Mistake 3: conflating canary with feature flags
Canary controls version exposure; flags control behavior exposure.
- Choose three technical metrics with thresholds.
- Choose two business metrics with thresholds.
- Set minimum observation duration per stage.
- Assign authority to halt promotion.
Good follow-up reads
Feature flag rollout workflowCode freeze and release candidate workflowRevert-first stabilization workflow