Deployment Strategies

This guide provides actionable steps, real-life examples, and best practices for implementing blue-green, canary, and rolling deployments in cloud-native environments (AWS, Azure, GCP) using Kubernetes, Terraform, and CI/CD tools.

---

Blue-Green Deployment

Blue-green deployment maintains two identical production environments (blue and green). Traffic is switched to the new version only after validation, enabling zero-downtime releases and easy rollbacks.

How to Implement (Kubernetes Example):

1. Deploy the new version as a separate deployment/service (e.g., myapp-green).

2. Test the green environment (QA, smoke tests).

3. Switch traffic by updating the service selector:

   kubectl patch service myapp-service -p '{"spec": {"selector": {"app": "myapp-green"}}}'

4. Monitor for issues. Roll back by switching the selector back to blue if needed.

Terraform Example (AWS ALB):

• Use two target groups (blue/green) and switch the ALB listener rule to point to the new target group.

Best Practices:

• Automate traffic switch in CI/CD (GitHub Actions, Azure Pipelines).

• Keep environments in sync using IaC (Terraform, Bicep).

• Monitor after cutover for quick rollback.

Common Pitfalls:

• Configuration drift between environments.

• Not testing green environment thoroughly before switch.

---

Canary Deployment

Canary deployment gradually routes a small percentage of traffic to the new version, increasing as confidence grows.

How to Implement (Kubernetes Ingress NGINX Example):

1. Deploy the new version alongside the stable version.

2. Use ingress annotations to split traffic:

   nginx.ingress.kubernetes.io/canary: "true"
   nginx.ingress.kubernetes.io/canary-weight: "10"

3. Gradually increase the canary weight (10% → 25% → 50% → 100%).

4. Monitor metrics and logs for errors or regressions.

GitHub Actions Example:

• Use workflow steps to update canary weights and run automated tests after each increment.

Best Practices:

• Automate canary progression and rollback based on health checks.

• Use feature flags for user-level canaries.

• Monitor user experience and error rates closely.

Common Pitfalls:

• Not monitoring canary traffic separately.

• Skipping incremental rollout steps.

---

Rolling Deployment

Rolling deployment updates pods or servers incrementally, ensuring some instances always serve traffic.

How to Implement (Kubernetes Example):

• Use a rolling update strategy in your deployment manifest:

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

• Apply the new deployment:

  kubectl apply -f deployment.yaml

• Kubernetes will update pods one at a time, maintaining availability.

Terraform Example (VMSS on Azure):

• Use rolling_upgrade_policy for Azure Virtual Machine Scale Sets.

Best Practices:

• Set appropriate maxUnavailable and maxSurge values for your SLA.

• Monitor deployment progress and health.

Common Pitfalls:

• Setting maxUnavailable too high, causing downtime.

• Not monitoring for failed updates.

---

Summary Table

Strategy	Downtime	Rollback	Complexity	Use Case
Blue-Green	Minimal	Easy	High	Major releases, zero-downtime
Canary	Minimal	Easy	Medium	Risk mitigation, feature rollout
Rolling	Low	Medium	Low	Routine updates, large clusters

---

References

• Kubernetes Deployment Strategies
• NGINX Ingress Canary
• Terraform Blue-Green Example
• Azure Rolling Upgrade
• AWS Blue/Green Deployments