Despliegues Blue-Green y Canary

Introducción

Desplegar a producción es riesgoso. Un mal deploy puede caer tu servicio, corromper datos o degradar la experiencia de usuario por horas. Las estrategias de deploy existen para reducir este riesgo controlando cómo el nuevo código llega a los usuarios y qué tan rápido puedes revertir si algo sale mal.

Estrategias de Deploy Comparadas

Estrategia	Nivel de Riesgo	Tiempo de Rollback	Complejidad	Mejor Para
Recreate	Alto	Lento (redeploy)	Baja	Solo ambientes dev/test
Rolling	Medio	Medio (detener rolling)	Baja	Servicios stateless simples
Blue-Green	Bajo	Instantáneo (switch tráfico)	Media	Cuando rollback instantáneo es crítico
Canary	Muy bajo	Rápido (devolver tráfico)	Alta	Cambios de alto riesgo, rollouts graduales
Feature Flags	Mínimo	Instantáneo (toggle off)	Media	Desacoplar deploy de release

Rolling Deployment

Reemplaza instancias viejas gradualmente con nuevas.

# Kubernetes rolling update
kubectl set image deployment/api api=myapp:v2.4.1
kubectl rollout status deployment/api

Trade-off: Durante el rollout, versiones viejas y nuevas coexisten. Si v2 rompe un contrato de datos, instancias v1 pueden fallar al leer datos escritos por v2.

Blue-Green Deployment

Mantiene dos ambientes idénticos. Uno está activo (blue), otro inactivo (green). Deploya en green, testea, luego cambia tráfico instantáneamente.

Antes:  Usuarios → [Load Balancer] → [Blue: v2.4.0]
                                     [Green: v2.4.0 inactivo]

Después: Usuarios → [Load Balancer] → [Blue: v2.4.0 inactivo]
                                     [Green: v2.4.1 activo]

Trade-off: Duplica costo de infraestructura. Requiere manejo cuidadoso de cambios de esquema de base de datos (ambas versiones deben funcionar con el mismo esquema).

Consideraciones de Base de Datos

Tipo de Cambio	¿Compatible Blue-Green?
Agregar columna (nullable)	Sí — código viejo la ignora
Agregar columna (non-nullable)	No — código viejo no puede insertar sin ella
Renombrar columna	No — código viejo referencia nombre viejo
Eliminar columna	No — código viejo puede seguir leyéndola
Agregar índice	Sí — ambas versiones se benefician

Regla: Blue-green requiere cambios de base de datos backward-compatible. Usa patrón expand-contract: agregar nueva columna (expand), deployar nuevo código, eliminar columna vieja (contract).

Canary Deployment

Enruta un pequeño porcentaje de tráfico a la nueva versión, monitorea métricas, luego aumenta gradualmente.

Paso 1: 1%  → [Canary v2.4.1], 99% → [Stable v2.4.0]
Paso 2: 5%  → [Canary v2.4.1], 95% → [Stable v2.4.0]
Paso 3: 25% → [Canary v2.4.1], 75% → [Stable v2.4.0]
Paso 4: 100% → [Canary v2.4.1 se convierte en stable]

# Kubernetes con Flagger (canary automatizado)
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: api
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  analysis:
    interval: 30s
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
      - name: request-duration
        thresholdRange:
          max: 500

Criterios de aborto: Si la tasa de error sube o la latencia excede el umbral, Flagger automáticamente hace rollback a 0% canary.

Feature Flags (Desacoplando Deploy de Release)

Deploya código a producción pero mantenlo oculto. Actívalo para usuarios específicos cuando esté listo.

# Feature flag estilo LaunchDarkly
if client.variation("new-checkout-flow", user_context, False):
    return new_checkout.handle(request)
return old_checkout.handle(request)

Usa Feature Flags Para	NO Uses Feature Flags Para
Nuevas capacidades de UI	Fixes de seguridad (no deberían ser toggleables)
Tests A/B	Parches de bugs críticos
Rollouts graduales de capacidades	Código de migración de datos
Kill switches para capacidades riesgosas

Métricas a Observar Durante Deploy

Métrica	Umbral Canary	Acción Si Se Viola
Tasa de error	< 0.1%	Rollback canary
Latencia p99	< línea base + 20%	Rollback canary
Throughput	Sin caída > 10%	Rollback canary
Métrica de negocio custom	Sin caída	Rollback canary

Lo que funciona

• Automatiza rollback — un humano presionando un botón a las 3 AM es poco confiable. Consulta pipelines CI/CD.
• Usa tráfico sintético — golpea el canary con tests de carga antes que usuarios reales
• Mantén deploys pequeños — cambios más pequeños son más fáciles de debuggear y más rápidos de revertir
• Un cambio a la vez — no combines un deploy con migración de base de datos y cambio de config
• Testea rollback — un rollback que nunca practicaste es una apuesta

Errores Comunes

• Deployar viernes por la tarde — estarás debuggeando todo el fin de semana
• No tener rollback automatizado — los rollbacks manuales toman 10x más tiempo
• Combinar múltiples cambios en un deploy — cuando falla, no sabes cuál causó el problema
• Ignorar métricas de canary porque “los tests pasaron” — tráfico de producción es la única prueba real
• Olvidar compatibilidad de esquema en blue-green — código viejo y nuevo debe coexistir durante el switch

Lectura Adicional

• Documentación oficial: consulta la referencia actualizada del framework o herramienta utilizada.
• Guías relacionadas: explora las guías de zero-downtime y deployment para profundizar.
• Patrones complementarios: revisa los patrones de diseño aplicables a tu stack tecnológico.
• Postmortems públicos: estudia incidentes reales de equipos que enfrentaron problemas similares en producción.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica despliegues blue-green y canary cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Temas Avanzados

Escenario: Pipeline de Despliegue para E-commerce

# ArgoCD Application: canary deployment
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payment-service
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 5        # 5% trafico a v2
        - pause: { duration: 5m }  # Observar 5 min
        - setWeight: 20       # 20% trafico
        - pause: { duration: 10m }
        - setWeight: 50       # 50% trafico
        - analysis:           # Analisis automatico
            templates:
            - templateName: success-rate
            args:
            - name: service-name
              value: payment-service
        - setWeight: 100      # 100% si pasa
  selector:
    matchLabels: { app: payment-service }
  template:
    spec:
      containers:
        - name: payment
          image: registry.example.com/payment:v2.1.0
          resources:
            requests: { cpu: 200m, memory: 256Mi }
            limits: { cpu: 500m, memory: 512Mi }

# AnalysisTemplate: criterios de exito
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
    - name: service-name
  metrics:
    - name: success-rate
      interval: 1m
      successCondition: result[0] >= 0.99
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            sum(rate(http_requests_total{
              service="{{args.service-name}}",
              status!~"5.."}[2m]))
            / sum(rate(http_requests_total{
              service="{{args.service-name}}"}[2m]))

Estrategias por tipo de cambio:
  | Cambio | Estrategia | Duracion |
  |--------|-----------|----------|
  | Fix de typo | Rolling | 2 min |
  | Actualizacion de dependencia | Rolling | 5 min |
  | Nueva feature UI | Blue-green | 10 min |
  | Refactor de logica | Canary 5->20->50->100 | 30 min |
  | Cambio de schema DB | Expand-contract | Multi-deploy |
  | Migracion de infraestructura | Shadow + canary | 1-2 horas |

Rollback automatico:
  - Tasa de error > 1% durante 2 min -> rollback
  - Latencia p99 > 2x baseline -> rollback
  - AnalysisTemplate falla 3 veces -> rollback
  - Rollback: ArgoCD revierte a revision anterior en 30s

Lecciones:
  - Canary con analisis automatico > canary manual
  - Define criterios de exito antes de desplegar
  - Rollback automatico reduce MTTR dramaticamente
  - Expand-contract para schema changes es obligatorio
  - Shadow deploy valida sin impacto en usuarios

Como manejo despliegues cross-region?

Usa ArgoCD ApplicationSet con clusters multiregion. Despliega secuencialmente: us-east primero, luego eu-west, luego ap-southeast. Pausa entre regiones para detectar problemas. Usa global load balancer (Route53, Cloudflare) para health checks. Si una region falla, las otras ya estan en la version nueva.

End of document. Review and update quarterly.

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts.

Errores Comunes en Producción

• Tratar la guía como un checklist para completar una vez en lugar de una práctica por evolucionar.
• Adoptar cada recomendación de golpe en lugar de comenzar con un cambio medido.
• Saltar la evaluación de madurez e imponer prácticas avanzadas a un equipo no preparado.
• No actualizar runbooks y expectativas de guardia al introducir nuevas prácticas.
• Ignorar datos reales de incidentes al priorizar qué partes de la guía aplicar primero.
• No asignar un responsable que revise decisiones trimestralmente.
• Copiar ejemplos sin adaptarlos a las herramientas y restricciones reales del equipo.
• Olvidar medir resultados antes de agregar la siguiente mejora.