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.

Instance 1: v1 ████ → v2 ████████████
Instance 2: v1 ████████ → v2 ████████
Instance 3: v1 ████████████ → v2 ████

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.

                   Traffic
                     │
              ┌──────┴──────┐
              │ Load Balancer│
              └──────┬──────┘
                     │
        ┌────────────┼────────────┐
        │            │            │
   ┌────┴────┐  ┌────┴────┐
   │  Blue   │  │  Green  │
   │  (v1)   │  │  (v2)   │
   │ ACTIVE  │  │ STANDBY │
   └─────────┘  └─────────┘

After validation, switch traffic to Green:

              ┌──────┴──────┐
              │ Load Balancer│
              └──────┬──────┘
                     │
        ┌────────────┼────────────┐
        │            │            │
   ┌────┴────┐  ┌────┴────┐
   │  Blue   │  │  Green  │
   │  (v1)   │  │  (v2)   │
   │ STANDBY │  │ ACTIVE  │
   └─────────┘  └─────────┘

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.

Phase 1:  v1 ████████████████████ (95%)
          v2 █ (5%)

Phase 2:  v1 ██████████████████ (75%)
          v2 ██████ (25%)

Phase 3:  v1 ██████████ (50%)
          v2 ██████████ (50%)

Phase 4:  v2 ████████████████████ (100%)