Greenhouse Deployment Strategies: Ship With Confidence

1. Deploy the new version to a greenhouse environment that matches production specs.
2. Route a small percentage of real traffic to the greenhouse.
3. Monitor key metrics closely.
4. Gradually increase traffic if everything looks good.
5. Promote to full production or roll back instantly.

# Kubernetes deployment with canary rollout
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1      # Allow 1 extra pod during update
      maxUnavailable: 0 # Never take pods offline during update
  template:
    spec:
      containers:
      - name: web
        image: my-app:2.1.0
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

Common Deployment Strategies Compared

Blue-Green Deployment

Two identical environments exist at all times. Blue is live, green is idle. When you're ready to deploy, you build the green environment, test it, then switch the load balancer from blue to green.

# Switch traffic from blue to green
kubectl patch service web-app -p '{"spec":{"selector":{"version":"green"}}}'

# If issues arise, switch back instantly
kubectl patch service web-app -p '{"spec":{"selector":{"version":"blue"}}}'

Pros: Instant rollback, zero downtime.
Cons: Requires double the infrastructure, complex database migration handling.

Canary Deployment

A small subset of users (5%, 10%) receives the new version while the rest stay on the old version. Traffic is gradually shifted based on metrics.

# Istio canary traffic split
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: web-canary
spec:
  hosts:
  - myapp.com
  http:
  - route:
    - destination:
        host: myapp
        subset: stable
      weight: 90
    - destination:
        host: myapp
        subset: canary
      weight: 10

Pros: Controlled risk, data-driven decisions.
Cons: Requires sophisticated traffic management, stateful sessions can be tricky.

Rolling Update

Pods are replaced one by one (or in batches) with the new version. This is the default strategy in most Kubernetes deployments.

Pros: Simple, efficient resource usage.
Cons: Longer deployment window, rollback requires keeping old version available.

Database Migration Strategies

Database changes are the hardest part of deployments because they're not easily reversible. Here's a safe approach:

1. Phase 1 — Deploy code that supports both schemas. Add new columns alongside old ones.
2. Phase 2 — Backfill data in a background job, keeping both schemas working.
3. Phase 3 — Deploy code that uses only the new schema. Remove references to old columns.
4. Phase 4 — Remove old columns in a separate deployment.

This "expand and contract" pattern ensures you can roll back at any point.

Monitoring During Deployment

Every deployment needs a dedicated "deployment dashboard" showing:

Set up automatic rollback triggers:

# Argo Rollouts canary analysis
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate-check
spec:
  metrics:
  - name: error-rate
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          rate(http_requests_total{status=~"5.."}[5m]) /
          rate(http_requests_total[5m])
    successCondition: result < 0.01

Conclusion

No deployment strategy is perfect for every situation. Blue-green excels when you need instant rollback. Canary is ideal for data-driven, gradual rollouts. Rolling updates are the simplest starting point. The key is to pick a strategy, automate it, and practice it. Teams that deploy confidently are teams that move fast — and fast teams build better products.