Rollout Progresivo y Canary Release, Explicado

Rollout progresivo es liberar un cambio para una fracción creciente del público (por ejemplo 1%, 5%, 25%, 100%), monitoreando métricas de guarda en cada etapa antes de avanzar. Canary release es un caso más específico de ese mismo principio, aplicado a la infraestructura de deploy: una versión nueva corre en paralelo con la antigua en un subconjunto pequeño de servidores, y la decisión de expandir suele automatizarse mediante métricas de error y latencia, no por una persona decidiendo a ojo. Los dos conceptos aparecen juntos con frecuencia porque resuelven el mismo problema (reducir el riesgo de un cambio en producción) en dos capas distintas del stack, y ambos se apoyan en la misma infraestructura de feature flags que ya cubrimos en la guía completa del cluster.

Qué es el rollout progresivo

Rollout progresivo (también llamado gradual rollout o phased rollout) es la práctica de exponer una funcionalidad nueva, o una versión nueva de una funcionalidad, a una fracción pequeña del público primero, e ir aumentando esa fracción en etapas discretas hasta llegar al 100%. La alternativa obvia, activar la llave para todo el mundo de una vez, convierte cualquier problema no detectado en un incidente de escala total; el rollout progresivo convierte el mismo problema en algo que afecta a una fracción pequeña y controlada, con tiempo de sobra para reaccionar antes de que se convierta en noticia.

La documentación de LaunchDarkly describe dos mecanismos distintos para esto: el rollout por porcentaje, en el que defines manualmente la fracción (por ejemplo 5%) y aumentas esa fracción a mano conforme ganas confianza, manteniendo el mismo conjunto de usuarios asignado mientras el valor no cambie; y el rollout progresivo propiamente dicho, en el que la plataforma aumenta el porcentaje automáticamente a lo largo de un período definido (por ejemplo, de 5% a 100% a lo largo de 24 horas, en etapas programadas). La diferencia práctica más citada por la propia LaunchDarkly es sutil, pero importa: un rollout progresivo reiniciado puede asignar un conjunto diferente de usuarios a la variación nueva, porque la elección de quién entra se vuelve a sortear en cada ejecución, mientras que un rollout por porcentaje simple mantiene el mismo grupo mientras la configuración no cambie.

En la práctica, la mayoría de los rollouts progresivos documentados sigue una secuencia parecida a esta, ajustada al volumen de tráfico y al apetito de riesgo de cada equipo: una etapa interna (equipo y QA, sin ningún usuario real expuesto), luego 1% de producción, luego 5 a 10%, luego 25 a 50%, y solo entonces 100%. La guía de Flagsmith sobre estrategias de deploy describe exactamente ese patrón con un ejemplo concreto: una flag new-payment-processor habilitada para el 1% de los usuarios y, si las métricas se ven bien, aumentada a 5%, luego 20%, y así sucesivamente hasta llegar al 100%.

Qué es canary release, y de dónde viene el nombre

Canary release es una técnica específica para reducir el riesgo de poner una versión nueva de software en producción, liberando el cambio lentamente para un subconjunto pequeño de infraestructura antes de expandirlo al resto, según la definición de Martin Fowler en el bliki que lleva el nombre de la técnica. El término viene de una práctica histórica de la minería: se llevaban canarios dentro de las minas de carbón como un sistema de alerta temprana, porque el pájaro moría antes que los mineros al respirar gases tóxicos, dando tiempo de evacuar antes de que el peligro afectara a las personas. Un canary release cumple el mismo papel: expone el problema en un subconjunto pequeño y controlado antes de que afecte a todo el público.

Fowler describe el canary release como pariente cercano del blue-green deployment: ambos empiezan implementando la versión nueva en infraestructura separada, sin que todavía apunte allí ningún tráfico de usuario real. La diferencia aparece después. En el blue-green, el cambio es completo y de una sola vez, todo el tráfico pasa de una infraestructura a la otra en el mismo instante, después de que la validación terminó. En el canary release, el tráfico de usuarios reales se dirige de forma creciente y gradual hacia la versión nueva, empezando por muestras pequeñas y aleatorias, pasando por empleados internos, y solo entonces expandiéndose por criterio demográfico, geográfico o por unidad de negocio, siempre con la opción de revertir rápidamente si algo sale mal.

La documentación de proveedores de nube refuerza el mismo diseño en la práctica: AWS documenta el canary deployment para funciones Lambda usando un alias con dos versiones y un peso de tráfico configurable, por ejemplo dirigiendo el 10% del tráfico a la versión nueva, manteniendo ese peso durante una ventana de validación (minutos a pocas horas) y, si una alarma configurada se dispara en ese intervalo, revirtiendo automáticamente el 100% del tráfico de vuelta a la versión antigua. Es la misma lógica del canario en la mina: una señal de alerta pequeña y controlada, antes de que el riesgo se propague.

La diferencia entre los dos conceptos

Rollout progresivo y canary release comparten el principio (exponer poco a poco, monitorear, decidir), pero se enfocan en capas diferentes del sistema y suelen operarlos equipos distintos.

Criterio	Rollout progresivo (feature flag)	Canary release
Foco principal	Usuario y funcionalidad: quién ve qué	Infraestructura y deploy: qué versión del código está activa
Quién decide el avance	Generalmente una persona (producto, ingeniería), manual o por regla de segmentación	Generalmente automatizado por métricas de error/latencia del pipeline de deploy
Unidad de segmentación	Usuario, cuenta, sesión (atribución estable por ID)	Servidor, instancia, pod o fracción de infraestructura
Qué se está probando	Si la funcionalidad se comporta bien para el negocio y para el usuario	Si la versión nueva del código es estable en producción (error, latencia, salud del servicio)
Herramienta típica	LaunchDarkly, Unleash, Flagsmith, PostHog, Statsig	Pipeline de deploy (AWS CodeDeploy/ECS, Kubernetes, Google Cloud Deploy)
Rollback	Apagar la flag, generalmente en segundos	Redirigir el tráfico de vuelta a la versión estable

Una forma simple de recordar la diferencia: el canary release resuelve si esa versión de código es segura para correr en producción, mientras que el rollout progresivo por feature flag resuelve si esa funcionalidad es segura para que la gente la use. En la práctica, las dos técnicas se combinan con frecuencia: haces el deploy de la versión nueva vía canary release (el código ya está corriendo, probado en un subconjunto de infraestructura), y usas un feature flag por encima para controlar quién, dentro de ese código ya desplegado, realmente ve la funcionalidad nueva. Canary controla dónde corre el código; el feature flag controla qué aparece para quién.

Métricas de guarda y rollback automático

El elemento que transforma un rollout progresivo de “aumentar el porcentaje y cruzar los dedos” en una práctica de ingeniería responsable son las métricas de guarda (guardrail metrics): los indicadores que no pueden empeorar mientras la exposición aumenta. Las más citadas en la documentación de deploy y de feature management son la tasa de error, la latencia (en particular los percentiles altos, p95 y p99, porque el promedio esconde los peores casos), la tasa de crash en aplicaciones móviles, e indicadores de negocio como conversión o tasa de fallas de pago cuando el cambio tiene potencial de afectar los ingresos directamente.

LaunchDarkly formaliza esta idea en lo que llama guarded rollout: la plataforma aumenta la exposición de una variación progresivamente mientras monitorea métricas conectadas (por integración, API, evento de SDK u OpenTelemetry), comparando estadísticamente el desempeño de la variación nueva contra la original en cada etapa. Si la comparación señala una regresión estadísticamente significativa, el rollout se pausa y notifica al equipo responsable; con el rollback automático habilitado, la propia plataforma revierte el cambio sin esperar a que una persona actúe.

El patrón de mercado, ilustrado por implementaciones como la de AWS para funciones Lambda, define el límite de forma explícita antes de que empiece el rollout (por ejemplo, una alarma de tasa de error por encima de un umbral sostenido durante algunos minutos) y usa una ventana de tiempo corta para no confundir un pico transitorio y pasajero con una regresión real. La lección común a toda esta documentación, de LaunchDarkly a AWS: cuando una métrica de guarda empeora, la respuesta correcta es reducir la exposición de vuelta, nunca seguir adelante esperando que “se estabilice solo”.

Cómo se conecta esto con los feature flags, y por qué no es un test A/B

El rollout progresivo depende, casi siempre, de la misma pieza de infraestructura que sostiene los feature flags: una regla que decide, por usuario o por sesión, si esa persona recibe la versión nueva. Por eso este tema aparece como una extensión natural de lo que ya cubrimos en la guía completa de feature flags: la release flag, el tipo de flag más común, existe justamente para permitir este tipo de liberación gradual y reversible.

Vale la pena reforzar una confusión común: el rollout progresivo no es un test A/B, aunque use un mecanismo parecido por debajo. Un test A/B asigna tráfico de forma fija entre variaciones (la misma fracción en cada brazo, de principio a fin del test) y termina con una decisión estadística sobre qué versión convierte más, con muestra y significancia calculadas antes de empezar. Un rollout progresivo aumenta la fracción expuesta con el tiempo hasta llegar al 100%, y termina cuando el cambio está liberado para todos, sin que exista necesariamente una pregunta de “qué variación es mejor” detrás. El objetivo de uno es mitigar riesgo de deploy; el objetivo del otro es medir efecto. Quien quiera entender exactamente dónde se cruza esa línea, y cuándo un rollout simple debería convertirse en un experimento de verdad, encuentra la comparación en profundidad en feature flags vs test A/B.

La misma distinción vale para la capa de ejecución: tal como cubrimos en la comparación entre test A/B client-side y server-side, un rollout progresivo de producto normalmente se decide en el servidor (la misma infraestructura de feature flag server-side), porque involucra lógica de negocio, permisos o datos sensibles que no deberían evaluarse en el navegador del usuario. Un canary release, en cambio, siempre es una decisión de infraestructura: ocurre en la capa de deploy, incluso antes de que cualquier flag decida qué aparece para quién.

Buenas prácticas: cómo planificar un rollout progresivo

No existe un número mágico universal para el tamaño del incremento o el tiempo de observación, porque eso depende del volumen de tráfico, de la criticidad del cambio y de qué tan rápido las métricas de guarda generan una señal confiable. Pero algunos principios aparecen de forma consistente en la documentación de LaunchDarkly, AWS y Flagsmith:

Decisión	Práctica recomendada	Por qué
Tamaño del primer incremento	Lo bastante pequeño para limitar el daño (1% es el valor más citado), nunca 10%+ en la primera etapa de un cambio de riesgo desconocido	Limita el “radio de explosión” en caso de que algo salga mal ya en la primera etapa
Tiempo de observación por etapa	Minutos a pocas horas en las etapas pequeñas; un día o más en las etapas grandes (25%, 50%)	Las etapas pequeñas tienen menos tráfico, así que tardan más en generar señal estadística confiable en métricas de negocio
Quién decide el avance	Automatizado por métrica de guarda siempre que sea posible; decisión manual como plan B, nunca por “ya lleva un tiempo activo”	Una decisión automatizada reacciona más rápido que una persona mirando un panel de vez en cuando
Qué monitorear	Tasa de error, latencia (p95/p99), tasa de crash, y al menos una métrica de negocio cuando el cambio afecta el embudo	Las métricas técnicas detectan fallas del sistema; las métricas de negocio detectan un problema que “funciona” pero perjudica al usuario
Cuándo revertir	En la primera señal sostenida de degradación, no en la primera fluctuación aislada	Reduce falsas alarmas por picos transitorios sin retrasar la reacción a un problema real

Un error común de quien recién empieza es tratar “aumentar el porcentaje” como un evento de calendario (avanzar cada viernes, por ejemplo), en vez de condicionarlo a la salud de la etapa actual. El rollout progresivo solo entrega el valor que promete cuando el avance depende de lo que muestran las métricas de guarda, no de cuánto tiempo ya pasó.

Hazlo automático en Donnu

Lanzar un cambio con seguridad es, en el fondo, el mismo problema que resolvemos para los experimentos: decidir con datos, no a ciegas, y nunca exponer al 100% del tráfico un riesgo desconocido de una sola vez. Donnu A/B ya resuelve la parte de asignación estable y sin flicker para quien quiere probar variaciones; si tu próximo paso es un rollout de funcionalidad (no experimentación), el principio es el mismo que describió esta guía: empieza pequeño, mide, y solo expande cuando la etapa anterior demuestre que es segura.

Si lo que necesitas hoy es medir qué variación convierte más, con muestra calculada y una lectura honesta, comienza una prueba gratis de 14 días. Si lo que necesitas es entender la base de feature flags antes de decidir tu stack de rollout, empieza por la guía completa de feature flags.

Referencias

• Fowler, M. CanaryRelease. martinfowler.com/bliki, 2014. martinfowler.com/bliki/CanaryRelease.html.
• LaunchDarkly. Progressive rollouts y Guarded rollouts. launchdarkly.com/docs/home/releases/progressive-rollouts y launchdarkly.com/docs/home/releases/guarded-rollouts.
• AWS. Implement Lambda canary deployments using a weighted alias. docs.aws.amazon.com/lambda.
• Unleash. Canary release vs rolling deployment: Rollback speed, risk, and resources. getunleash.io/blog.
• Flagsmith. 8 Types of Deployment Strategies (And How Feature Flags Help). flagsmith.com/blog.