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

Last updated