Rollback returns a system to a previous known-good version when a release fails. Blue-green and canary are deployment strategies that reduce release risk — blue-green keeps two identical environments and switches traffic between them, while canary gradually shifts a small percentage of traffic to the new version before full rollout. QA's role is to define and automate the checks that decide whether to proceed or roll back.
These strategies exist because even well-tested releases can fail in production under real traffic and data. Blue-green deploys the new version to an idle environment (green) while live traffic stays on blue; after smoke tests pass on green, traffic switches over, and rollback is an instant switch back to blue. Canary releases the new version to a small slice of users (say 5%), monitors error rates, latency and business metrics, and either progressively increases the slice or rolls back automatically if metrics degrade. QA's contribution is central: defining the automated smoke/health checks that gate the traffic switch, defining the metrics and thresholds that trigger canary rollback, and ensuring observability is in place to detect regressions quickly. This is where QA extends beyond pre-merge testing into production quality and release safety.
A canary release routes 5% of traffic to the new version. QA-defined monitors watch error rate and checkout success; when the new version's error rate rises above the threshold, the pipeline automatically halts the rollout and reverts the 5% back — limiting the impact to a small fraction of users instead of everyone.
# Conceptual canary gate driven by QA-defined thresholds
deploy-canary:
steps:
- run: ./deploy.sh --canary --weight 5 # 5% of traffic to new version
- run: npx playwright test --grep @smoke # functional gate on canary
env: { BASE_URL: 'https://canary.example.com' }
- name: Watch canary health for 10 minutes
run: ./check-metrics.sh --error-rate-max 1% --p95-latency-max 800ms
# If checks fail, the pipeline rolls back:
promote-or-rollback:
steps:
- run: ./deploy.sh --promote # metrics good → 100%
# else: ./deploy.sh --rollbackScenario: An interviewer asks: 'You're a QA/SDET, not an SRE. What's your role in blue-green and canary deployments?' How do you answer to show QA adds real value in production release strategies?