Blue-Green & Canary Deployment Strategy

## ROLE

You are a deployment engineering specialist and release manager who has orchestrated thousands of production deployments across diverse infrastructure. You have implemented blue-green deployments for monolithic applications, canary releases for microservices, and progressive delivery pipelines that automatically promote or roll back based on real-time metrics analysis. You understand the infrastructure requirements, traffic management patterns, database migration challenges, and observability needs for each deployment strategy and can recommend the right approach based on application architecture and risk tolerance.

## OBJECTIVE

Design and implement a zero-downtime deployment strategy for [APPLICATION TYPE: monolithic web application / microservices on Kubernetes / serverless functions / multi-tier application with database / mobile backend API / custom] deployed on [PLATFORM: Kubernetes / ECS / Azure App Service / Cloud Run / VM-based with load balancer / custom]. The application serves [TRAFFIC PATTERN: steady traffic / bursty with peaks / global multi-region / low-traffic internal tool] with [SLA: 99.9% / 99.95% / 99.99%] uptime requirement and [DEPLOYMENT FREQUENCY: daily / weekly / bi-weekly / monthly] releases.

## TASK: DEPLOYMENT STRATEGY DESIGN

### Strategy Selection Matrix

Evaluate deployment strategies for [APPLICATION TYPE] using this decision framework:

**Blue-Green Deployment** — Best when: you need instant full rollback capability, your application is a monolith or tightly coupled, you can afford to run double infrastructure during transition, and database schema changes are backward compatible. Cost: 2x infrastructure during deployment window. Complexity: Medium. Rollback time: seconds (DNS/LB switch).

**Canary Deployment** — Best when: you need to limit blast radius of bad releases, you have good observability to detect issues in small traffic percentages, your services are independently deployable, and you want data-driven promotion decisions. Cost: 1x + small canary overhead. Complexity: High (requires traffic splitting and analysis). Rollback time: seconds (route traffic away from canary).

**Rolling Update** — Best when: you have stateless services behind load balancers, you want zero additional infrastructure cost, you can tolerate running two versions simultaneously during rollout, and rollback means rolling forward with a fix or backward with a new rollout. Cost: 0 additional. Complexity: Low. Rollback time: minutes (new rollout).

**Progressive Delivery (Canary + Automated Analysis)** — Best when: you deploy frequently and need automated quality gates, you have comprehensive metrics and can define success criteria programmatically, and you want to eliminate human judgment from promotion decisions. Cost: canary overhead + tooling. Complexity: Very high. Rollback time: automatic upon failure detection.

For [APPLICATION TYPE] with [SLA] requirements and [DEPLOYMENT FREQUENCY], recommend [STRATEGY: primary strategy + fallback strategy] with justification.

### Blue-Green Implementation

Design the complete blue-green deployment architecture:

**Infrastructure Setup:** Provision two identical environments (Blue and Green) with [INFRASTRUCTURE: duplicate Kubernetes namespaces / separate ECS services / parallel VM groups behind ALB target groups / separate Cloud Run revisions]. Both environments connect to [SHARED RESOURCES: database / cache / message queue / object storage] that must support both versions simultaneously.

**Traffic Switching Mechanism:** Configure [SWITCH METHOD: Kubernetes Service selector update / ALB listener rule swap / DNS weighted routing / Istio VirtualService / Nginx upstream swap / cloud provider traffic manager] to route 100% of traffic between Blue and Green. Provide the exact configuration and the switching command or automation script. The switch must complete in under [SECONDS: 5 / 10 / 30] with zero dropped requests. Implement connection draining on the old environment with [DRAIN TIMEOUT: 30s / 60s / 120s] to allow in-flight requests to complete.

**Database Migration Strategy:** This is the hardest part of blue-green deployments. Handle schema changes using the expand-contract pattern:
1. **Expand:** Add new columns/tables without removing old ones. Both Blue and Green versions can read/write using the old schema. Apply migration before deployment.
2. **Deploy:** Switch traffic from Blue to Green. Green uses new columns but also writes to old columns for backward compatibility.
3. **Contract:** After confirming Green is stable and rollback is no longer needed, remove old columns in a subsequent migration.

Provide [NUMBER: 2-3] specific database migration examples for [DATABASE: PostgreSQL / MySQL / MongoDB / custom] showing the expand-contract SQL/migration files for common scenarios: adding a required column, renaming a column, and splitting a table.

**Rollback Procedure:** Document the exact rollback steps: detect issue (automated alert or manual observation within [WINDOW: 5 min / 15 min / 1 hour]), switch traffic back to Blue (exact command), verify Blue is healthy and processing requests, investigate Green failure, and decide whether to fix-forward on Green or prepare a new release. Provide a runbook with decision tree for the on-call engineer.

### Canary Implementation

Design the progressive canary release pipeline:

**Traffic Splitting:** Configure [TOOL: Istio VirtualService / Linkerd TrafficSplit / AWS ALB weighted target groups / Nginx canary annotations / Argo Rollouts / Flagger / custom] to route a percentage of traffic to the canary version.

**Rollout Stages:** Define the canary progression for [APPLICATION TYPE]:
- Stage 1: [PERCENTAGE: 1-5%] traffic for [DURATION: 5-10 min] — smoke test, catch immediate crashes
- Stage 2: [PERCENTAGE: 10-20%] traffic for [DURATION: 10-15 min] — validate error rates and latency
- Stage 3: [PERCENTAGE: 50%] traffic for [DURATION: 15-30 min] — full-scale validation
- Stage 4: [PERCENTAGE: 100%] traffic — promotion complete

At each stage, evaluate these automated quality gates:

**Success Criteria (all must pass to promote):**
- Error rate: canary error rate <= baseline error rate + [TOLERANCE: 0.1% / 0.5% / 1%]
- Latency: canary p99 latency <= baseline p99 + [TOLERANCE: 10% / 20% / 50ms]
- Success rate: canary HTTP 2xx rate >= [THRESHOLD: 99% / 99.5% / 99.9%]
- Custom metric: [BUSINESS METRIC: conversion rate / checkout completion / API response validity] within [TOLERANCE] of baseline
- Zero critical log patterns: no OOMKill, no panic/fatal, no [CUSTOM PATTERN]

**Automatic Rollback Triggers (any one triggers immediate rollback):**
- Error rate exceeds [CRITICAL: 5% / 10%] absolute
- Latency p99 exceeds [CRITICAL: 2x / 3x] baseline
- Pod restart count > [NUMBER: 2 / 5] within evaluation window
- Custom metric drops below [FLOOR: absolute minimum acceptable]

Provide the complete configuration for [TOOL] that implements this canary pipeline with automated analysis and rollback.

### CI/CD Pipeline Integration

Design the deployment pipeline that integrates with [CI/CD: GitHub Actions / GitLab CI / Jenkins / ArgoCD / Spinnaker / custom]:

**Pipeline Stages:**
1. Build: compile, test, security scan, create container image
2. Deploy to staging: full deployment using [STRATEGY] with automated smoke tests
3. Approval gate: [GATE TYPE: automated metrics check / manual approval / scheduled window / change advisory board]
4. Deploy to production: execute [STRATEGY] with monitoring
5. Post-deployment validation: automated integration tests against production, synthetic monitoring check, and [CUSTOM VALIDATION]
6. Cleanup: remove old environment (blue-green) or scale down canary baseline

Provide the complete pipeline configuration file for [CI/CD] with all stages, environment variables, approval gates, and deployment commands.

### Multi-Region Deployment Orchestration

If deploying across [REGIONS: us-east-1 + eu-west-1 / multiple regions / custom], design the regional rollout strategy: deploy to [CANARY REGION: lowest traffic region] first, validate for [DURATION: 30 min / 1 hour / 4 hours], then progressively deploy to remaining regions. Configure global traffic manager to route away from regions during deployment. Define the blast radius at each stage and the circuit breaker that halts global rollout if the canary region shows degradation.