# Despliegues Blue-Green, Canary y Rolling Update

**Categoría:** DevOps y cloud · **Nivel:** Intermedio · **Lectura:** 11 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/devops-cloud/despliegues-blue-green-canary-y-rolling-update/

## Respuesta rápida

Actualizar una aplicación reemplazándola de golpe —apagar la vieja, prender la nueva— corta el servicio y, si la versión nueva falla, deja todo caído. Las **estrategias de despliegue** resuelven actualizar **sin cortes** y con **vuelta atrás rápida**. Hay tres clásicas. El **rolling update** reemplaza las copias de la aplicación de a poco, unas por otras, de modo que siempre hay versiones sirviendo; es la más simple y viene incorporada en [Kubernetes](../kubernetes-para-principiantes-pods-deployments-y-services/index.md). El **blue-green** mantiene dos entornos completos —el actual («blue») y el nuevo («green»)— y cambia todo el tráfico de uno al otro de una vez; si algo sale mal, se vuelve al anterior al instante, pero cuesta el doble de infraestructura por un rato. El **canary** libera la versión nueva a una **pequeña porción** de usuarios primero, observa si todo va bien, y solo entonces la extiende al resto; es el más seguro para cambios riesgosos, pero requiere buenas [métricas](../observabilidad-con-opentelemetry-prometheus-y-grafana/index.md) para decidir. En las tres, la pieza crítica es el **rollback**: poder volver a la versión anterior rápido cuando algo falla.

## El problema del despliegue

La forma ingenua de actualizar una aplicación es apagarla, poner la versión nueva y prenderla. Tiene dos problemas serios. Uno: durante el reemplazo, **el servicio no responde** —hay una caída, corta o larga—. Dos, más grave: si la versión nueva tiene un fallo que no se detectó, **todos los usuarios lo sufren de golpe** y volver atrás es lento, porque hay que repetir el proceso al revés.

> **El objetivo: actualizar sin caídas y poder volver**
>
> Las estrategias de despliegue persiguen dos metas. La primera es **cero tiempo de caída**: los usuarios nunca ven el servicio interrumpido durante una actualización. La segunda, igual de importante, es **limitar y revertir el daño**: si la versión nueva falla, que afecte a la menor cantidad de gente posible y se pueda volver a la anterior en segundos. Las tres estrategias que siguen son formas distintas de equilibrar esas metas contra el costo y la complejidad.

## Rolling Update: reemplazo gradual

El **rolling update** (actualización gradual) parte de varias copias idénticas de la aplicación corriendo la versión vieja, y las va **reemplazando de a una o de a pocas** por copias con la versión nueva. En todo momento hay copias sirviendo tráfico, así que no hay corte; al final, todas están en la versión nueva.

- **Ventaja:** es simple y no requiere infraestructura extra, porque reutiliza las mismas copias. Viene incorporada en el [deployment de Kubernetes](../kubernetes-para-principiantes-pods-deployments-y-services/index.md).
- **Costo:** durante la transición conviven las dos versiones atendiendo tráfico —la aplicación tiene que tolerarlo—, y volver atrás implica hacer el reemplazo inverso, que lleva su tiempo.

## Blue-Green: dos entornos, un cambio

El **blue-green** mantiene **dos entornos completos e idénticos**. El «blue» es el que está en producción con la versión actual. El «green» es donde se despliega y prueba la versión nueva, sin recibir tráfico real. Cuando el green está listo y verificado, se cambia **todo el tráfico** del blue al green de una sola vez, reapuntando el balanceador.

- **Ventaja:** la vuelta atrás es **instantánea**. Si el green falla, se reapunta el tráfico de nuevo al blue, que sigue intacto. Y la versión nueva se prueba en un entorno real antes de recibir tráfico.
- **Costo:** requiere el **doble de infraestructura** funcionando a la vez durante la transición, lo que se paga —aunque sea por un rato—.

Es una excelente opción cuando la vuelta atrás instantánea vale más que el costo temporal de duplicar, y cuando conviene validar la versión nueva en un entorno idéntico al de producción antes de exponerla.

## Canary: probar con pocos primero

El **canary** (canario, por los canarios que se llevaban a las minas para detectar gas) libera la versión nueva primero a una **porción pequeña** de usuarios —por ejemplo, el 5 %— mientras el resto sigue en la versión vieja. Se **observan las métricas y los errores** de ese grupo reducido; si todo va bien, se aumenta el porcentaje gradualmente hasta el 100 %; si aparecen problemas, se revierte afectando solo a esa pequeña porción.

> **Atención**
>
> La decisión de avanzar o revertir un canary se basa en datos: ¿aumentaron los errores en el grupo nuevo? ¿empeoró la latencia? Sin buenas [métricas](../observabilidad-con-opentelemetry-prometheus-y-grafana/index.md), el canary es a ciegas y pierde su gracia. Por eso va de la mano de la observabilidad, y en entornos maduros el análisis se automatiza. Es la estrategia más segura para cambios riesgosos —limita el impacto de un fallo a pocos usuarios— pero también la más compleja de operar.

En las tres estrategias, la pieza crítica común es el **rollback**: la capacidad de volver a la versión anterior rápido cuando algo falla. A menudo se combina con **banderas de función** (feature flags), que permiten activar o desactivar una funcionalidad sin desplegar de nuevo. Y no hay una estrategia «mejor»: se elige según cuán riesgoso sea el cambio y cuántos recursos haya, el mismo criterio de equilibrio del [costo de infraestructura](../como-reducir-costos-de-infraestructura-en-la-nube/index.md).

## Errores frecuentes

- **Desplegar apagando y prendiendo.** Corta el servicio y expone a todos al fallo de golpe.
- **No tener un rollback probado.** Una estrategia sin vuelta atrás rápida no protege ante un fallo real.
- **Canary sin métricas.** Si no se mide el grupo de prueba, no hay forma de decidir; es un canary ciego.
- **Olvidar las migraciones de base de datos.** Un cambio de esquema incompatible entre versiones rompe la convivencia de ambas.
- **Blue-green sin contemplar el costo.** Duplicar infraestructura tiene un precio que hay que prever.
- **Suponer que la app tolera dos versiones a la vez.** En rolling y canary conviven; hay que diseñarlo para eso.
- **Elegir la estrategia más compleja sin necesidad.** Para muchos casos, un rolling update simple alcanza.

## Preguntas frecuentes

**¿Qué es un rolling update?**
Es la estrategia de despliegue que actualiza una aplicación reemplazando sus copias de forma gradual, de a una o de a pocas por vez, en lugar de todas a la vez. Se parte de varias copias idénticas corriendo la versión vieja y se las va sustituyendo por copias con la versión nueva, de manera que en todo momento hay copias disponibles sirviendo tráfico y el servicio nunca se corta; al terminar, todas quedan en la versión nueva. Su gran ventaja es la simplicidad: no requiere infraestructura adicional porque reutiliza las mismas copias, y de hecho es la estrategia que viene incorporada de fábrica en Kubernetes a través de su objeto de deployment. Sus contrapartidas son que durante la transición conviven las dos versiones atendiendo tráfico simultáneamente, lo que obliga a que la aplicación tolere esa convivencia, y que volver atrás no es instantáneo, porque implica realizar el reemplazo en sentido inverso, lo que lleva su tiempo. Es una opción muy adecuada para la mayoría de los despliegues cotidianos.

**¿Qué es un despliegue blue-green?**
Es una estrategia que mantiene dos entornos completos e idénticos en paralelo. Uno, llamado azul, es el que está en producción atendiendo a los usuarios con la versión actual. El otro, llamado verde, es donde se despliega y prueba la versión nueva sin que reciba tráfico real. Cuando la versión del entorno verde está lista y verificada, se cambia todo el tráfico del azul al verde de una sola vez, reapuntando el enrutador o balanceador de carga. Su gran ventaja es que la vuelta atrás es prácticamente instantánea: si la versión nueva presenta problemas, basta con reapuntar el tráfico de nuevo al entorno azul, que se mantuvo intacto durante todo el proceso, sin necesidad de reconstruir nada. Además, permite validar la versión nueva en un entorno idéntico al de producción antes de exponerla. Su principal costo es que requiere tener el doble de infraestructura funcionando simultáneamente durante la transición, lo que representa un gasto que hay que prever, aunque sea temporal.

**¿Qué es un despliegue canary?**
Es la estrategia que libera la versión nueva de forma gradual empezando por una porción pequeña de los usuarios, por ejemplo un cinco por ciento, mientras la gran mayoría continúa usando la versión anterior. El nombre alude a los canarios que se llevaban a las minas para detectar gases peligrosos antes de que afectaran a los mineros. Durante esa exposición reducida se observan con atención las métricas y los errores del grupo que recibió la versión nueva; si los indicadores se mantienen sanos, se aumenta progresivamente el porcentaje hasta alcanzar a todos los usuarios, y si aparecen problemas se revierte afectando únicamente a esa porción pequeña. Es la estrategia más segura para cambios riesgosos, precisamente porque limita el impacto de un eventual fallo a muy pocos usuarios, pero también es la más compleja de operar y depende por completo de contar con buenas métricas para poder decidir de forma objetiva si conviene avanzar o revertir. Por eso va siempre de la mano de una buena observabilidad.

**¿Cuál de las tres estrategias es la mejor?**
No hay una mejor en abstracto: la elección es un equilibrio entre seguridad, costo de infraestructura y complejidad operativa, y depende de cuán riesgoso sea el cambio y de cuántos recursos se tengan. El rolling update es el más simple y económico, y suele ser suficiente para la mayoría de los despliegues cotidianos de bajo riesgo. El blue-green conviene cuando lo más valioso es poder revertir de forma instantánea y validar en un entorno idéntico al de producción, y cuando se puede asumir el costo temporal de duplicar la infraestructura. El canary es el indicado para cambios especialmente riesgosos o de gran alcance, donde vale la pena la complejidad adicional a cambio de limitar el impacto de un posible fallo a una fracción mínima de usuarios. Un error común es elegir la estrategia más sofisticada por defecto: muchas veces un rolling update bien hecho resuelve el problema sin la carga operativa de las otras. La clave transversal, presente en las tres, es tener siempre un mecanismo de rollback rápido y probado.

**¿Por qué es tan importante el rollback?**
Porque ninguna cantidad de pruebas previas garantiza que una versión nueva funcione perfectamente en producción, donde el tráfico real, los datos reales y las condiciones reales pueden revelar problemas que no aparecieron antes. El rollback, es decir la capacidad de volver a la versión anterior de forma rápida y confiable, es lo que convierte un despliegue en una operación segura en lugar de una apuesta: si algo sale mal, se revierte y se contiene el daño mientras se investiga con calma. Las tres estrategias de despliegue giran en buena medida alrededor de facilitar ese rollback: el blue-green lo hace instantáneo al conservar el entorno anterior intacto, el canary lo hace de bajo impacto al haber expuesto solo a pocos usuarios, y el rolling update lo permite revirtiendo el reemplazo. A esto se suman las banderas de función, que permiten activar o desactivar una funcionalidad sin necesidad de un nuevo despliegue, ofreciendo una vía de reversión aún más rápida y granular. Tener un rollback probado, y no solo teórico, es una de las marcas de una operación madura.

**¿Qué pasa con la base de datos al desplegar sin cortes?**
Es uno de los puntos más delicados y a menudo olvidados. Cuando se despliega sin cortes con estrategias como rolling o canary, durante la transición conviven la versión vieja y la versión nueva de la aplicación atendiendo tráfico al mismo tiempo, y ambas suelen compartir la misma base de datos. Si la versión nueva introduce un cambio de esquema incompatible con la vieja —por ejemplo, elimina o renombra una columna que la versión anterior todavía usa— se produce un fallo, porque una de las dos versiones se encuentra con una estructura que no espera. La forma correcta de manejarlo es diseñar los cambios de base de datos para que sean compatibles hacia atrás y aplicarlos en pasos: primero cambios aditivos que ambas versiones toleren, y solo después de que la versión vieja haya desaparecido por completo se realizan los cambios destructivos. Ignorar este detalle es una causa frecuente de que un despliegue teóricamente sin cortes termine igualmente rompiendo el servicio, así que las migraciones de datos deben planificarse como parte integral de la estrategia de despliegue.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección GNU/Linux](https://underc0de.org/foro/gnu-linux/). Despliegue y operación de servicios.
2. **Underc0de, foro.** [Sección Programación](https://underc0de.org/foro/programacion/). Entrega de nuevas versiones de software.

### Documentación oficial

1. **Martin Fowler.** [Blue-Green Deployment](https://martinfowler.com/bliki/BlueGreenDeployment.html). La descripción de referencia de la estrategia.
2. **Martin Fowler.** [Canary Release](https://martinfowler.com/bliki/CanaryRelease.html). Cómo se libera de forma gradual.
3. **Kubernetes.** [Rolling Update Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment). La estrategia incorporada en Kubernetes.
4. **Google.** [Canarying Releases (SRE Workbook)](https://sre.google/workbook/canarying-releases/). Cómo se automatiza el análisis de un canary.

## Guías relacionadas

- [Kubernetes para principiantes](../kubernetes-para-principiantes-pods-deployments-y-services/index.md)
- [Pipelines CI/CD](../como-crear-pipelines-ci-cd-con-github-actions/index.md)
- [Observabilidad](../observabilidad-con-opentelemetry-prometheus-y-grafana/index.md)
- [Backups y recuperación](../recuperacion-ante-desastres-y-backups-en-devops/index.md)
- [Índice de DevOps y cloud](../index.md)