# Qué es progressive delivery? Canary, blue-green y flags URL: https://codebasechat.com/es/journal/que-es-progressive-delivery Type: blog Locale: es Published: 2026-11-03 Updated: 2026-11-03 --- > El progressive delivery libera los cambios en pasos pequeños y comprobados con métricas. Así encajan canary, blue-green y feature flags, y por dónde empezar. Si se pregunta qué es progressive delivery, la respuesta corta es esta: una forma de publicar software en la que un cambio llega a producción en pasos pequeños y controlados, y cada paso se comprueba con métricas reales antes de empezar el siguiente. Si los números empeoran, la liberación se detiene o se revierte sola. Así usted deja de apostar toda su base de usuarios a un único despliegue. La situación le resultará conocida. Un pull request está aprobado, la CI está en verde, el despliegue sale un martes por la tarde y veinte minutos después alguien pregunta en Slack por qué la latencia del checkout se ha duplicado. El progressive delivery existe para acortar esa conversación y para que el problema afecte al 5 % del tráfico en lugar del 100 %. ## ¿Qué cambia realmente el progressive delivery? La entrega continua responde a una pregunta: ¿podemos enviar este cambio a producción de forma segura? El progressive delivery añade una segunda: ¿quién lo ve primero y qué nos indica que debemos parar? El movimiento clave es separar desplegar de liberar. Desplegar significa que el código nuevo ya se ejecuta en los servidores. Liberar significa que los usuarios quedan expuestos a él. Una vez separados los dos, usted puede desplegar un miércoles a las 14:00 y liberar a su ritmo, a una audiencia elegida y con una vía de retorno. La mayoría de las fuentes coinciden en tres bloques: el desvío gradual de tráfico (canary), los entornos paralelos (blue-green) y los feature flags. No son rivales. Los equipos maduros usan los tres, cada uno en una capa distinta. ## Canary releases: ¿cuánto tráfico y quién decide? Una liberación canary envía una pequeña parte del tráfico a la versión nueva, por ejemplo el 5 %, mientras el resto sigue en la versión anterior. Si la tasa de errores, la latencia y la saturación se mantienen dentro de sus umbrales, esa parte crece: 5 %, 25 %, 50 %, 100 %. Si no, el tráfico vuelve a la versión anterior. El problema es que los repartos finos requieren algo capaz de repartir el tráfico. La [documentación de Argo Rollouts](https://argo-rollouts.readthedocs.io/en/stable/concepts/) explica que los porcentajes precisos de canary necesitan un gestor de tráfico, como un service mesh o un ingress controller. Sin uno, solo se obtiene un control grueso basado en el número de réplicas, de modo que el «5 %» puede significar en realidad «un pod de cada veinte». Así se ve un canary por etapas en un manifiesto de Argo Rollouts. Es corto a propósito. `strategy: canary: steps: - setWeight: 5 - pause: { duration: 10m } # revisar paneles o ejecutar el análisis - setWeight: 25 - pause: { duration: 10m } - setWeight: 100`Omita el canary si su servicio recibe tan poco tráfico que el 5 % son unas pocas peticiones por hora. Esperará una señal que nunca llega o, peor, tomará el ruido por seguridad. En servicios de bajo tráfico, los feature flags dirigidos a usuarios internos son una mejor primera barrera. ![Tres frascos llenos de arena azul a distintos niveles, que representan porcentajes de tráfico por etapas](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/97a746-i1.webp) ## Blue-green: ¿cuándo merece la pena un segundo entorno completo? Blue-green mantiene dos entornos de producción completos. Blue atiende a los usuarios. Green recibe la versión nueva y se prueba mientras no tiene tráfico. Cuando está satisfecho, el tráfico pasa de uno a otro. Según la documentación de Argo Rollouts, el cambio es de golpe: la versión antigua conserva todo el tráfico de producción hasta que la nueva está verificada, y entonces el reparto pasa de 0 % a 100 %. Esa es su fortaleza y también su debilidad. La vuelta atrás es un único cambio, y por eso es rápida. Pero la prueba se hace antes de que lleguen usuarios reales, y el coste es el doble de infraestructura mientras ambos lados están activos. Merece la pena si gestiona un servicio con estado o de alto impacto, donde una liberación parcial resultaría confusa, por ejemplo una ruta de pago en la que dos versiones nunca deben atender una misma petición a la vez. No lo haga si su migración de base de datos no puede ejecutarse con las dos versiones a la vez, porque entonces la «vuelta atrás instantánea» es una ficción. ![Dos vías de tren paralelas con una palanca de cambio, que representan entornos blue-green](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/aba476-i2.webp) ## ¿Dónde encajan los feature flags? Canary y blue-green funcionan a nivel de infraestructura. Los feature flags funcionan dentro de la aplicación. Un flag envuelve un camino de código en una condición que puede cambiar en tiempo de ejecución, sin volver a desplegar. Eso convierte a los flags en la herramienta de control más fina del conjunto. Puede exponer una funcionalidad a los empleados, después al 1 % de las cuentas y luego a un segmento de clientes, y desactivarla en segundos si se comporta mal. Algunos equipos los tratan como una técnica más entre varias, mientras que otros los consideran el habilitador de todo el enfoque. En la práctica, la segunda visión se sostiene: en cuanto quiere liberar por audiencia y no por servidor, necesita un flag. Los flags tienen también su coste. Cada flag es una rama que sus pruebas deben cubrir y una tarea de limpieza que alguien tiene que cerrar. Si quiere la versión más larga, explicamos la mecánica y la deuda en [qué es un feature flag](/journal/what-is-a-feature-flag). Trate cada flag como temporal por defecto, con un responsable y una fecha de retirada. Herramientas como LaunchDarkly y Statsig venden la capa de gestión: reglas de segmentación, registros de auditoría, despliegues graduales por porcentaje y experimentos. ## ¿Qué hace que un rollout sea progresivo y no solo lento? La automatización. Un despliegue que se detiene diez minutos mientras una persona mira un panel es un despliegue lento. Se convierte en progressive delivery cuando una máquina comprueba las métricas y toma la decisión. El patrón es el mismo en todas partes: - Defina las señales antes de la liberación: tasa de errores, latencia p95 y una métrica de negocio, como la finalización del checkout. - Defina los umbrales que significan «parar», escritos en la configuración y no en la cabeza de alguien. - Deje que el controlador promocione, retenga o revierta según esas señales. Argo Rollouts se integra con proveedores de métricas para que un rollout se promocione o se aborte automáticamente según superen o no las comprobaciones. Una de las fuentes que revisamos lo dice sin rodeos: el progressive delivery sin reversión automática es solo un despliegue lento. Estamos de acuerdo. ![Manos de una desarrolladora sobre un teclado junto a un monitor con gráficos de métricas desenfocados](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/33c271-i3.webp) ### ¿Qué métricas deberían condicionar un rollout? Mantenga un conjunto pequeño. Tres o cuatro señales en las que ya confía valen más que veinte que nunca ha configurado como alerta. Un punto de partida razonable: la tasa de errores HTTP 5xx del canary frente a la base de referencia, la latencia p95 del canary frente a la base, la saturación (CPU, memoria, profundidad de colas) y una métrica de producto. Compare el canary con la base en el mismo momento, no con «la semana pasada», porque los patrones de tráfico cambian. Aquí es donde su stack de observabilidad deja de ser un extra. Si no puede segmentar las métricas por versión o por variante de flag, no podrá distinguir el canary de la base, y todo el enfoque se viene abajo. Nuestra introducción a [qué es la observabilidad](/journal/what-is-observability) explica cómo llegar a ese punto. ### ¿Cómo encaja el progressive delivery con el trunk-based development? Encajan bien. El [trunk-based development](/journal/what-is-trunk-based-development) mantiene las ramas cortas e integra cambios pequeños con frecuencia. El riesgo es que trabajo sin terminar o sin probar llegue a la rama principal con más frecuencia. El progressive delivery es lo que hace seguro ese flujo: el código entra en el tronco, se despliega oculto detrás de un flag y se libera de forma gradual. Los lotes pequeños junto con una exposición gradual también abaratan la depuración. Cuando un canary falla, la lista de sospechosos es un solo cambio y no cuarenta. Quien haya buscado a mano, con git bisect, en una semana de commits fusionados a las 23:00 sabe lo que eso vale. ## ¿Cuál es un primer paso realista para un equipo de 10 a 30 ingenieros? No empiece instalando un service mesh. Empiece por lo más pequeño que le dé un botón de parada. - **Semana 1:** ponga una funcionalidad arriesgada detrás de un flag y libérela primero a su propio equipo. - **Semana 2:** añada paneles por versión para la tasa de errores y la latencia. Si sus herramientas no pueden segmentar por versión, arregle eso primero. - **Semana 3 en adelante:** pase un servicio sin estado a un controlador de canary, con dos o tres etapas y una cancelación automática ante un aumento de errores. Mídalo en horas, no en una «sensación de seguridad». Cuente cuántos incidentes quedaron contenidos en una porción pequeña de usuarios y cuánto tardó la vuelta atrás. Esos dos números le dirán si funciona para su equipo. ## ¿Dónde suelen fallar los rollouts progresivos? En tres sitios, y ninguno es el controlador. **Migraciones de base de datos.** Un canary significa que dos versiones de su código usan la misma base de datos al mismo tiempo. Si la versión N+1 elimina o renombra una columna que la versión N todavía lee, el canary tumba la base de referencia. La solución sencilla es expandir y contraer: añada primero la columna nueva, despliegue código que escriba en ambas, rellene los datos, cambie las lecturas y solo después elimine la columna antigua. **Sesiones fijas y cachés.** Si un usuario salta entre la versión antigua y la nueva en cada petición, aparecen errores que nadie consigue reproducir. Fije a cada usuario a una variante durante todo el rollout, mediante cookie, identificador de cuenta o evaluación del flag. **Métricas con retraso.** Una métrica de conversión que se actualiza cada hora no puede condicionar un paso de canary de diez minutos. Durante el rollout, condicione con señales rápidas (errores, latencia) y revise la métrica de negocio lenta antes de pasar del 50 % al 100 %. ### ¿Cómo saber qué está activo en el repositorio? El progressive delivery reparte una liberación entre archivos de configuración, definiciones de flags, manifiestos de rollout y paneles. Pasados unos meses, la pregunta «¿qué flag protege la nueva ruta de facturación y quién es su responsable?» se convierte en la rutina de siempre: grep, blame y preguntar a alguien. Es un problema de lectura de código, no de herramientas. Buscar en el repositorio por la clave del flag y seguir cada referencia hasta su punto de llamada es la forma más rápida de encontrar flags muertos y rollouts a medio terminar. Una herramienta que responda «¿dónde se evalúa este flag y qué pasa cuando está desactivado?» a partir de su código real le ahorra más tiempo que otro panel más. ## Lo que omitiríamos Omita el blue-green para todo si su factura de infraestructura ya es motivo de conversación. Omita los canaries en servicios con casi nada de tráfico. Omita cualquier herramienta de rollout que nadie del equipo sepa depurar a las 3 de la mañana. El problema real no es la estrategia que elija. Es la distancia entre enviar código y saber qué hace en producción. El progressive delivery reduce esa distancia una porción de tráfico cada vez, y la primera porción es la que importa: que sea pequeña, que sea observable y que tenga un interruptor de apagado. ## FAQ ### ¿Qué es progressive delivery en pocas palabras? Es publicar software enviándolo primero a una pequeña parte de los usuarios, comprobar métricas reales y ampliar la audiencia solo si los números aguantan. Si no aguantan, la liberación se detiene o se revierte. ### ¿Cuál es la diferencia entre progressive delivery y entrega continua? La entrega continua hace que todo cambio sea liberable. El progressive delivery controla cómo llega una liberación a los usuarios: por porcentaje de tráfico, por audiencia o por entorno, con comprobaciones de métricas entre pasos. ### ¿Un canary release es lo mismo que progressive delivery? No. El canary es una técnica. El progressive delivery es la práctica más amplia, que también incluye los despliegues blue-green, los feature flags y el análisis y la reversión automatizados. ### ¿Necesito Kubernetes para el progressive delivery? No. Los feature flags funcionan en cualquier aplicación. Los porcentajes finos de canary sí necesitan algo que reparta el tráfico, como un service mesh, un ingress controller o un balanceador con enrutamiento ponderado. ### ¿Cuándo es mejor blue-green que un canary? Cuando una liberación parcial sería confusa o insegura, por ejemplo en una ruta de pago donde dos versiones no deben atender peticiones a la vez. El coste es el doble de infraestructura mientras ambos entornos están activos. ### ¿Qué métricas deberían condicionar un rollout progresivo? Empiece por la tasa de errores del canary frente a la base de referencia, la latencia p95 y una métrica de producto rápida. Compare ambas versiones al mismo tiempo y mantenga el conjunto pequeño. ### ¿Cómo se relacionan los feature flags con el progressive delivery? Los flags funcionan dentro de la aplicación, así que puede liberar por audiencia en lugar de por servidor. Son el control más fino, pero cada flag necesita un responsable y una fecha de retirada.