Blue-Green deployment và Canary deployment là gì?

Blue-Green deployment: duy trì hai production environments (blue=current live, green=new version).

• Deploy lên green, chạy integration tests, rồi switch traffic tại load balancer (nginx upstream, AWS ALB target groups, Kubernetes ingress) — switch instant, không có downtime.
• Rollback instant: nếu issue phát hiện sau deploy, switch traffic back về blue — green vẫn còn đó.
• Implementation với load balancer: Nginx upstream block với weight; AWS ALB forward rules; Kubernetes service selector switch.
• Cost: phải maintain 2 environments song song — expensive cho large infrastructure.
• Database migrations: challenge lớn nhất — migration phải backward-compatible với cả blue và green code (không thể drop column trong green nếu blue vẫn dùng).
• Canary deployment: deploy phiên bản mới cho một phần nhỏ users (1-5%), monitor metrics (error rate, latency, business metrics), rồi dần tăng percentage nếu ổn.
• Metrics cần monitor: error rate tăng đột biến, P99 latency tăng, conversion rate giảm, custom business metrics (orders/minute).
• Rollback trigger: tự động rollback nếu error rate vượt threshold.
• Implementation: Kubernetes với Flagger hoặc Argo Rollouts tự động canary với metric-based promotion; feature flags như LaunchDarkly cho canary ở application level.
• A/B testing vs Canary: A/B test new feature/UI cho subset users để measure business impact; Canary là risk reduction strategy cho infrastructure changes — có thể kết hợp cả hai.

Blue-Green deployment: maintain two production environments (blue = current live, green = new version).

• Deploy to green, run integration tests, then switch traffic at the load balancer (nginx upstream, AWS ALB target groups, Kubernetes ingress) — the switch is instant with no downtime.
• Instant rollback: if an issue is detected after deployment, switch traffic back to blue — green remains intact.
• Implementation with a load balancer: Nginx upstream block with weight; AWS ALB forward rules; Kubernetes service selector switch.
• Cost: must maintain 2 environments simultaneously — expensive for large infrastructure.
• Database migrations: the biggest challenge — migrations must be backward-compatible with both blue and green code (cannot drop a column in green if blue still uses it).
• Canary deployment: deploy the new version to a small subset of users (1-5%), monitor metrics (error rate, latency, business metrics), then gradually increase the percentage if stable.
• Metrics to monitor: sudden spikes in error rate, increased P99 latency, decreased conversion rate, custom business metrics (orders/minute).
• Rollback trigger: automatically roll back if error rate exceeds a threshold.
• Implementation: Kubernetes with Flagger or Argo Rollouts automates canary promotion based on metrics; feature flags like LaunchDarkly for canary at the application level.
• A/B testing vs Canary: A/B tests a new feature/UI for a subset of users to measure business impact; Canary is a risk-reduction strategy for infrastructure changes — the two can be combined.