Back to the Playbook
Build & VerificationBV-03
How to plan a canary rollout
Plan limited exposure with pre-agreed evaluation; an approved plan alone never executes a production rollout.
Product statusAssisted workflowTeklens plans and assesses; deploying the canary and every rollout action are separately authorised operations by your team.
Input3 required inputsRelease candidate and control version · Eligible traffic, reliability measures and recovery capability · Initiative focus and approved Product Brain guidance
SkillsPlan or assess a canary rollout · Prepare task context · Review an artifact against agreed criteriaReliability Engineer + Reliability Engineer Agent
OutcomeCanary rollout plan: exposure plan, evaluation signals and thresholds, recovery mechanism and owner, then the assessment and decision.Artifact: Canary rollout plan
Owner
Reliability Engineer
Human-led
Participants · Agents
EngineerProduct ManagerReliability Engineer Agent
Trigger
A release candidate and its current control version are ready.
Required context
CodeRelease candidate and control versionAnalyticsEligible traffic, reliability measures and recovery capabilityProduct BrainInitiative focus and approved Product Brain guidance
Optional context
ConfluenceSLO definitionArchitectureExposure constraints
Skills
Plan or assess a canary rolloutPrepare task contextReview an artifact against agreed criteria
Suggested conversation arc
- 1Agree exposure and recovery boundariesIdentify a bounded eligible population, candidate/control versions, risk allowance and recovery owner; stop planning expansion if meaningful comparison or recovery is unavailable.Skills: Prepare task context
- 2Draft evaluation and rollout planSpecify initial exposure, observation windows, candidate-versus-control signals and expand/pause/rollback criteria. Separate deployment from feature availability.Skills: Plan or assess a canary rollout
- 3Observe an authorised canaryOnly through separately authorised operational execution, obtain actual candidate/control measurements and rollout events. Preserve versions, exposure and observation duration; a plan is not evidence of deployment.
- 4Decide expand, pause or recoverCompare evidence with pre-agreed criteria, considering insufficient traffic and uncertainty. Record the release owner’s decision; any operational action remains separately authorised.Skills: Review an artifact against agreed criteria
Output
Canary rollout plan: exposure plan, evaluation signals and thresholds, recovery mechanism and owner, then the assessment and decision.
Artifacts
Creates: Canary rollout plan
What good looks like
- Candidate/control observations and decision criteria are explicit.
- Execution remains separate from planning and recommendation.
- No healthy-canary claim without real observations.
Quality gate
The release owner decides expand, pause or roll back against the pre-agreed criteria.
Destination
ConfluenceGitHub
Usually next
People and agents work from the same Product Brain. The owner stays accountable. Assigned agents prepare and check. A named person approves at the gate.
Choose the path that matches your role.
Set the Product AI direction with us, or test the shared Product Brain on real work with Jira and code.