Deployment Strategies

Deploying software to production is the final — and most critical — stage of a CI/CD pipeline. The deployment strategy you choose determines how much risk you take, how fast you can roll back, and how users experience changes.

---

Why Deployment Strategy Matters

A poor deployment strategy can cause:

• Downtime — users cannot access the application
• Data loss — database migrations gone wrong
• Cascading failures — one bad deploy takes down other services
• Slow recovery — unable to roll back quickly

A good deployment strategy provides:

• Zero or minimal downtime
• Fast rollback capability
• Gradual exposure to catch issues early
• Confidence to deploy frequently

---

Common Deployment Strategies

1. Recreate (Big Bang)

Stop the old version, deploy the new version.

v1 ████████████████ STOP
                         START v2 ████████████████
         ↑ Downtime ↑

Aspect	Details
Downtime	Yes — during the switch
Complexity	Very low
Rollback	Redeploy old version
Cost	Lowest
Use case	Development environments, non-critical services

2. Rolling Update

Gradually replace instances of the old version with the new version.

Aspect	Details
Downtime	None
Complexity	Low
Rollback	Roll forward or reverse the rolling update
Cost	Low (uses existing infrastructure)
Use case	Default for most Kubernetes deployments

# Kubernetes rolling update configuration
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: myapp
          image: myapp:v2.0.0
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10

3. Blue-Green Deployment

Run two identical environments: Blue (current) and Green (new). Switch traffic after validation.

graph TD
  subgraph Before["Before switch"]
    T1["Traffic"] --> LB1["Load Balancer"]
    LB1 --> B1["Blue (v1) — ACTIVE"]
    LB1 --> G1["Green (v2) — STANDBY"]
  end
  subgraph After["After validation: switch traffic to Green"]
    T2["Traffic"] --> LB2["Load Balancer"]
    LB2 --> B2["Blue (v1) — STANDBY"]
    LB2 --> G2["Green (v2) — ACTIVE"]
  end
  Before -.->|"switch"| After

Aspect	Details
Downtime	None
Complexity	Medium
Rollback	Instant — switch traffic back to Blue
Cost	Higher (double infrastructure during deploy)
Use case	Critical applications requiring instant rollback

4. Canary Deployment

Route a small percentage of traffic to the new version. Gradually increase if metrics look good.