Deployment Strategies: Blue/Green, Canary, and Rolling Explained

Why Deployment Strategy Matters

Shipping code is easy. Shipping code *safely* — with zero downtime, instant rollback, and controlled blast radius — requires a deliberate deployment strategy. The right choice depends on your tolerance for risk, your infrastructure, and how quickly you need to recover from a bad deploy.

Rolling Deployments

A rolling deployment replaces instances of the old version with the new version gradually, one (or a few) at a time. At any moment during the rollout, both old and new versions are serving traffic.

# Kubernetes rolling update configuration
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0      # No instances down at once
      maxSurge: 1            # One extra instance during rollout
  replicas: 4

Pros: Simple, no extra infrastructure, minimal resource overhead.

Cons: Mixed versions in production during rollout; APIs must be backward-compatible; rollback requires another rolling update (slow).

Best for: Stateless applications with backward-compatible changes and moderate risk tolerance.

Blue/Green Deployments

Blue/green runs two identical production environments simultaneously — blue (current) and green (new). Traffic is switched instantly from blue to green via a load balancer or DNS change.

# Blue/green with PandaStack CLI
# 1. Deploy new version to "green" slot (not yet live)
panda deploy --env production-green --branch main

# 2. Run smoke tests against green
curl -f https://green.your-app.pandastack.io/health

# 3. Switch traffic to green
panda traffic switch --from production-blue --to production-green

# 4. Keep blue running for instant rollback
# If something goes wrong:
panda traffic switch --from production-green --to production-blue

Pros: Zero-downtime deployments; instant rollback (just flip traffic back); green is fully tested before receiving live traffic.

Cons: Requires double the infrastructure during the transition; database migrations must be backward-compatible with both blue and green simultaneously.

Best for: Mission-critical applications where downtime is unacceptable and instant rollback is required.

Canary Deployments

A canary deployment sends a small percentage of real traffic to the new version while the majority continues to hit the old version. You monitor error rates, latency, and business metrics on the canary, then gradually increase its traffic share.

# Traffic splitting: 5% canary, 95% stable
# nginx upstream configuration
upstream backend {
  server stable-backend:3000 weight=95;
  server canary-backend:3000 weight=5;
}

# Canary rollout phases
panda deploy --env canary --branch main

# Phase 1: 5% of traffic
panda traffic set --env canary --weight 5

# Monitor for 30 minutes, check error rates
# Phase 2: 25%
panda traffic set --env canary --weight 25

# Phase 3: 100% — retire old version
panda traffic set --env canary --weight 100
panda deploy:retire --env stable

Pros: Real production traffic validates the new version; blast radius is limited to the canary percentage; data-driven rollout decisions.

Cons: Requires traffic-splitting infrastructure; mixed versions must be API-compatible; metrics analysis adds operational overhead.

Best for: High-traffic applications where real-user validation is more valuable than synthetic testing.

Choosing the Right Strategy

# Decision framework
decision:
  zero_downtime_required: true
  instant_rollback_required: true
  → blue/green

  zero_downtime_required: true
  want_real_traffic_validation: true
  have_monitoring_infrastructure: true
  → canary

  low_risk_change: true
  stateless_application: true
  cost_sensitive: true
  → rolling

Most teams start with rolling deployments because they require no extra infrastructure. As your application grows and the cost of a bad deployment rises, you graduate to blue/green or canary.

Database Migrations and Deployments

Every deployment strategy must account for database schema changes. The safest pattern is expand and contract:

# Step 1 (Deploy N): Add new column, keep old column
ALTER TABLE users ADD COLUMN display_name VARCHAR(255);

# Step 2: Deploy new application code that writes to both columns
# Step 3 (Deploy N+1): Remove old column once all instances use new one
ALTER TABLE users DROP COLUMN username;

This ensures any deployment strategy — rolling, blue/green, or canary — works safely because both old and new application versions are compatible with the database schema at every point in the rollout.

Connect your deployment pipeline to PandaStack at [dashboard.pandastack.io](https://dashboard.pandastack.io) and pair it with GitHub Actions to implement any of these strategies with automatic triggers, health checks, and rollback capabilities.