Estrategias de deploy 2026: Blue-Green vs Canary vs Rolling

No existe una única mejor estrategia de despliegue. Los rolling updates son el estándar para servicios stateless porque no cuestan nada extra; blue-green es la opción correcta cuando necesitas un rollback instantáneo de todo el sistema; los lanzamientos canary justifican su complejidad cuando un mal lanzamiento saldría caro y tienes métricas lo bastante buenas para detectarlo. Feature flags, shadow traffic y recreate cubren los casos restantes. Cada estrategia difiere en cuatro ejes: cuántas versiones corren a la vez, quién ve la nueva y cuándo, qué tan rápido puedes volver atrás y cuánto cuesta. Esta guía cubre cada estrategia, cómo ejecutarla en Kubernetes, serverless y bases de datos, y cómo elegir una.

Rolling deployment: el estándar para servicios stateless

Un rolling update reemplaza instancias antiguas por nuevas en lotes. En cualquier momento, algunas instancias ejecutan v1 y otras v2, y el balanceador de carga envía tráfico a ambas. La capacidad se mantiene cerca de lo normal y no hace falta ningún entorno extra.

En Kubernetes es el comportamiento nativo de un Deployment. Dos campos lo controlan: maxSurge (cuántos pods extra pueden existir por encima del número deseado) y maxUnavailable (cuántos pods pueden estar caídos durante la actualización). Ambos tienen 25% por defecto.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # un pod extra cada vez
      maxUnavailable: 0    # nunca bajar de 6 pods listos
  template:
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: checkout
          image: registry.example.com/checkout:2.4.0
          readinessProbe:
            httpGet: { path: /healthz/ready, port: 8080 }
          lifecycle:
            preStop:
              exec: { command: ["sleep", "5"] }

Tres cosas hacen o rompen un rolling update:

• Readiness probes. El pod nuevo no debe recibir tráfico hasta que pueda atender. Sin probe, Kubernetes considera el contenedor listo en el momento en que arranca.
• Graceful shutdown. El sleep del preStop da tiempo al endpoint controller para quitar el pod del Service antes de que llegue el SIGTERM. Después, tu proceso debe terminar las peticiones en curso dentro de terminationGracePeriodSeconds.
• Compatibilidad. v1 y v2 atienden peticiones en paralelo, así que los contratos de API, formatos de caché, esquemas de mensajes y esquema de base de datos deben funcionar para ambas.

Rolling tiene dos debilidades: no hay ninguna puerta entre lotes más allá de "los pods quedaron listos", así que una versión que arranca bien pero devuelve respuestas erróneas se despliega hasta el final; y el rollback (kubectl rollout undo) es otro rolling update, por lo que tarda tanto como tardó el rollout.

Blue-green deployment: cambio instantáneo, rollback instantáneo

Blue-green mantiene dos entornos completos. Blue atiende producción; green recibe la nueva versión, se prueba contra dependencias reales y luego asume todo el tráfico en un único cambio. Blue sigue en pie hasta que tengas confianza, y después se convierte en el destino del siguiente lanzamiento.

El cambio en sí es la decisión de diseño clave:

Mecanismo de cambio	Tiempo de cutover	Notas
Target group del balanceador / backend del Ingress	Segundos	Preferido; preciso y reversible
Ruta de service mesh (Istio, Linkerd)	Segundos	También permite un paso canary antes del cambio completo
Cambio de selector del Service en Kubernetes	Segundos	Simple; funciona sin herramientas extra
Registro DNS	Minutos a horas	Depende del TTL y de la caché de los clientes; evítalo para rollback

En Kubernetes, la versión mínima son dos Deployments (checkout-blue, checkout-green) y un Service cuyo selector cambias de version: blue a version: green. Argo Rollouts lo formaliza con strategy.blueGreen, que gestiona un Service activo y uno de preview, ejecuta un análisis opcional contra el preview y puede esperar una promoción manual (autoPromotionEnabled: false).

Blue-green encaja bien cuando:

• Necesitas un rollback de todo el sistema medido en segundos, por ejemplo en pagos, venta de entradas o cargas reguladas con ventanas de cambio explícitas.
• Varios servicios deben cambiar juntos y un estado mixto v1/v2 no es aceptable.
• Quieres ejecutar una prueba de integración o de carga completa contra la infraestructura de producción antes de exponer a los usuarios.

Los costes: capacidad doble durante el cambio, las mismas reglas de base de datos que en rolling (el cambio puede revertirse, así que green no debe escribir datos que blue no pueda leer) y el drenado de conexiones de larga duración en el lado antiguo.

Lanzamientos canary y progressive delivery

Un canary envía una pequeña parte del tráfico, normalmente 1–5%, a la nueva versión, observa las métricas durante una ventana fija y luego aumenta la proporción paso a paso. Si una métrica supera su umbral en cualquier paso, el tráfico vuelve automáticamente a la versión estable. El rollout se guía por evidencia, no por el reloj.

Kubernetes nativo no puede hacer esto. Un Deployment con dos réplicas de v2 y dieciocho de v1 da aproximadamente un 10% del tráfico, pero no puedes fijar la división, y se mueve a medida que los pods se reprograman. Una división precisa necesita una de estas opciones:

• Argo Rollouts, un reemplazo del Deployment con un bloque strategy.canary, un plugin de enrutado de tráfico para tu Ingress, Gateway API o mesh, y recursos AnalysisTemplate que consultan Prometheus, Datadog, New Relic, CloudWatch o un webhook.
• Flagger, un operator que deja tu Deployment intacto, crea una copia primaria y manipula los pesos del mesh o del Ingress según comprobaciones de métricas definidas en un recurso Canary.
• Un mesh o un HTTPRoute de Gateway API con backends ponderados, controlado por tu propio pipeline. Funciona, pero estás reconstruyendo el bucle de análisis por tu cuenta.

Una definición de pasos canary con Argo Rollouts se ve así:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: checkout
spec:
  replicas: 10
  strategy:
    canary:
      canaryService: checkout-canary
      stableService: checkout-stable
      trafficRouting:
        plugins:
          argoproj-labs/gatewayAPI:
            httpRoute: checkout-route
      steps:
        - setWeight: 5
        - pause: { duration: 10m }
        - analysis:
            templates:
              - templateName: error-rate-and-latency
        - setWeight: 25
        - pause: { duration: 15m }
        - setWeight: 50
        - pause: {}            # promoción manual a partir de aquí

El AnalysisTemplate referenciado arriba es donde está el trabajo real. Uno bueno compara el canary con la versión estable en la misma ventana, no contra un número fijo: tasa de errores, latencia p95 o p99 y una señal de negocio, como el éxito del checkout. Define la condición de fallo sobre el delta y exige que la métrica siga mal durante más de un intervalo antes de abortar, o el ruido normal hará fallar lanzamientos sanos.

Canary es la estrategia más potente y la más exigente. Necesitas labels de métricas que distingan canary de estable, tráfico suficiente para que una porción del 5% produzca cifras significativas y enrutado sticky si un usuario que toque ambas versiones rompería algo. Para servicios de bajo tráfico, usa blue-green o flags.

Feature flags, dark launches, shadow traffic y recreate

Las feature flags separan deploy de release. El código sale apagado, detrás de una flag desactivada, y el equipo la activa para usuarios internos, luego para un porcentaje y luego para un segmento como un plan o un país. La infraestructura ejecuta una versión; la flag decide el comportamiento. Es la única estrategia que apunta a usuarios en lugar de a peticiones, y permite que varios equipos entreguen cambios independientes en un mismo deploy. El coste es higiene de código: las flags deben eliminarse una vez activadas al 100%, y una flag evaluada en un hot path necesita caché local, nunca una llamada de red. Consulta feature flags, estrategias de despliegue y pruebas A/B para los detalles operativos.

Shadow (traffic mirroring) envía una copia de las peticiones reales a la nueva versión y descarta sus respuestas. Los usuarios solo ven la versión estable; el equipo compara logs, latencia y tasas de error entre ambas. Istio y Envoy soportan mirroring de forma nativa; Argo Rollouts lo expone como setMirrorRoute. El shadowing es excelente para validar una reescritura o una nueva dependencia bajo carga real, pero solo para lecturas. Las escrituras espejadas duplicarían efectos secundarios, así que la versión shadow necesita su propio almacén de datos o un stub idempotente para cualquier cosa que mute estado.

Recreate detiene todas las instancias antiguas y después arranca las nuevas. Siempre tiene downtime, así que solo es correcto cuando dos versiones realmente no pueden coexistir: un scheduler singleton, un servicio que mantiene un lock exclusivo, un formato de caché incompatible sin ruta de migración. En Kubernetes, define strategy.type: Recreate. Hazlo a propósito, con ventana de mantenimiento, no por accidente.

Estrategias de despliegue en plataformas serverless y edge

Las plataformas serverless dan rolling y canary gratis, pero con controles más limitados.

• AWS Lambda usa versiones de función y aliases. Un alias puede enrutar una proporción ponderada de invocaciones a una segunda versión, y CodeDeploy automatiza la rampa con las configuraciones Linear (incrementos fijos cada N minutos), Canary (un paso pequeño y luego todo) y AllAtOnce, haciendo rollback según alarmas de CloudWatch. La provisioned concurrency en la nueva versión evita cold starts durante la transición.
• Cloud Run conserva todas las revisiones y permite dividir el tráfico entre ellas por porcentaje o tag. Desplegar con --no-traffic y luego mover el tráfico gradualmente es un canary; mover el 100% de golpe manteniendo la revisión antigua caliente es blue-green.
• Azure Functions usa deployment slots con swap, que es blue-green por construcción.
• Las plataformas edge (Cloudflare Workers, Vercel, Netlify) despliegan de forma atómica y mantienen los despliegues anteriores direccionables, así que el rollback es cambiar un puntero; Cloudflare Workers también soporta división por porcentaje entre dos versiones.

La restricción recurrente en serverless es el estado: cualquier datastore compartido por dos versiones enfrenta las mismas reglas de compatibilidad que en Kubernetes. La plataforma solo resuelve la parte de cómputo.

Bases de datos: la parte que comparten todas las estrategias

Toda estrategia de cero downtime ejecuta dos versiones de la aplicación contra una base de datos durante algún periodo, y todo rollback ejecuta la versión antigua contra un esquema que la versión nueva puede haber cambiado. Ambos hechos llevan a la misma regla: los cambios de esquema deben ser compatibles con la versión anterior durante al menos un lanzamiento.

El patrón es expand-then-contract:

1. Expand. Añade la nueva columna, tabla o índice. Conserva la antigua. Despliega código que escribe en ambas y lee de la antigua.
2. Migra. Haz el backfill por lotes, con un job que pueda pausarse y reanudarse.
3. Cambia las lecturas. Despliega código que lee de la forma nueva pero sigue escribiendo en ambas, para que un rollback siga teniendo datos válidos.
4. Contract. Cuando ya no sea posible volver al lanzamiento anterior, deja de escribir en la forma antigua y elimínala.

Ejecuta la migración como un paso separado, antes del rollout de la aplicación, nunca dentro del arranque de un pod. En Kubernetes eso es un Job lanzado por el pipeline o un pre-step de Argo Rollouts; en serverless es una etapa del pipeline. Las sentencias ALTER TABLE largas que toman locks pertenecen a herramientas como pg-osc, gh-ost o la creación concurrente de índices de Postgres. El playbook completo, incluido cómo manejar cambios destructivos y la propiedad entre varios servicios, está en estrategias de migraciones de bases de datos para entornos de producción.

La elección de estrategia afecta a la base de datos de una forma: cuanto más tiempo coexisten dos versiones, más tiempo queda abierta la ventana de dual-write. Un rolling update de diez minutos tolera una ventana corta; un canary mantenido al 50% durante un día, o una flag activada a lo largo de semanas, exige que el estado expand sea una configuración estable y probada.

Tabla comparativa y checklist de decisión

Criterio	Rolling	Blue-green	Canary	Feature flags	Shadow	Recreate
Downtime	Ninguno con probes	Ninguno	Ninguno	Ninguno	Ninguno (usuarios intactos)	Sí
Velocidad de rollback	Minutos (rollout inverso)	Segundos (volver a cambiar)	Segundos (peso a 0)	Instantáneo (flag off)	N/A, nada expuesto	Minutos más downtime
Coste extra de infra	Un lote (maxSurge)	Duplicado completo durante el cambio	Unas pocas réplicas	Ninguno	Duplicado para la parte espejada	Ninguno
Control de tráfico	Solo por número de instancias	Todo o nada	Porcentaje o header preciso	Por usuario, segmento, plan	Copia, no enrutado	Ninguno
Complejidad	Baja; nativo en todo orquestador	Media; dos entornos y un cambio	Alta; necesita router, métricas, análisis	Media; servicio de flags y disciplina de limpieza	Alta; necesita mesh y aislamiento de escrituras	Muy baja
Compatibilidad de BD	Dos versiones coexisten brevemente	Dos versiones coexisten; cambio reversible	Dos versiones coexisten horas o días	Una versión; ambos caminos de la flag deben ser compatibles	Shadow no debe escribir	Una versión; las migraciones pueden romper
Ideal para	Servicios stateless, lanzamientos pequeños y frecuentes	Cambios coordinados, SLAs de rollback estrictos, ventanas reguladas	Servicios de alto tráfico y alto coste de fallo con buenas métricas	Lanzamientos de producto, exposición gradual por segmento, pruebas A/B	Reescrituras, nuevas dependencias, validación de rendimiento	Singletons, upgrades incompatibles, mantenimiento programado

Checklist de decisión

Recórrelo en orden. El primer "sí" suele zanjar la cuestión.

• ¿Las versiones antigua y nueva no pueden ejecutarse al mismo tiempo? Recreate, en ventana de mantenimiento. Luego corrige el diseño para que sea la última vez.
• ¿Necesitas probar contra la infraestructura de producción antes de que ningún usuario vea el cambio, o revertir un sistema entero en segundos? Blue-green.
• ¿Un mal lanzamiento sale caro, y tienes métricas por versión y tráfico suficiente para que una porción pequeña sea significativa? Canary, con análisis automatizado. Sin esas métricas, un canary es un rolling update lento con pasos de más.
• ¿El riesgo está en un comportamiento del producto y no en el binario, o necesitas lanzar primero a clientes concretos? Feature flags, encima de la estrategia de infraestructura que ya uses.
• ¿Estás reemplazando un servicio o una dependencia y quieres pruebas de que se comporta bajo carga real antes de que importe? Shadow traffic para lecturas, y luego una de las anteriores para el cambio real.
• ¿Ninguna de las anteriores? Rolling. Es el estándar por una razón.

Dos comprobaciones transversales aplican sea cual sea la respuesta:

• Toda estrategia salvo recreate exige migraciones expand-then-contract. Si el equipo no puede comprometerse con eso, ningún truco de enrutado de tráfico hará seguro el lanzamiento.
• Readiness probes, graceful shutdown y un rollback que realmente se haya ensayado importan más que la etiqueta de la estrategia. Un rolling update bien ejecutado supera a un canary que nadie ha abortado nunca. Conecta el rollback al mismo pipeline de CI/CD que hace el deploy, y practícalo en staging.
• Las estrategias se combinan. Rolling más flags es la configuración SaaS habitual; blue-green con un paso canary conserva el rollback rápido y reduce el radio de impacto; shadow seguido de canary es el camino más seguro al migrar sistemas heredados pieza a pieza. Distintos servicios en el mismo clúster de Kubernetes pueden usar estrategias distintas.

Recomendación

Empieza con rolling updates y probes bien ajustadas para todo servicio stateless; son gratis y cubren la mayoría de lanzamientos. Añade feature flags en cuanto más de un equipo entregue en el mismo servicio, para que deploy y release dejen de ser el mismo evento. Lleva un servicio a canary solo cuando tenga tráfico real, métricas por versión y un coste de fallo que justifique operar Argo Rollouts o Flagger; de lo contrario, un canary da ceremonia sin evidencia. Reserva blue-green para cambios coordinados y sistemas con un requisito estricto de rollback, y reserva recreate para el raro singleton. Elijas lo que elijas, trata la base de datos como la restricción que manda: las migraciones expand-then-contract son lo que hace que cualquiera de estas estrategias sea segura de revertir. En Arvucore solemos recomendar arreglar primero las migraciones y el ensayo de rollback, y elegir la estrategia de tráfico después.