Blue-Green Deployment

Resumen

En Blue-Green deployment, mantenés dos entornos de producción idénticos. En todo momento, uno está activo —blue— y el otro inactivo —green—. Cuando desplegás una nueva versión, la instalás en el entorno inactivo, hacés smoke tests, y si todo está bien, cambiás el tráfico —típicamente a nivel de load balancer—. El entorno que quedó inactivo se convierte en el nuevo green para el próximo deploy.

La gran ventaja es el rollback instantáneo: si la nueva versión falla, volvés a switchear el tráfico al entorno anterior. No hay que re-deployar la versión vieja, no hay que esperar builds. Un cambio de load balancer y listo.

Alcance y supuestos

Cubre Blue-Green, sus variantes, y contraste con canary y rolling. Asume familiaridad con estrategias de deploy.

Modelo mental

Dos pistas de baile idénticas en una fiesta. Todos bailan en la pista azul. El DJ prepara la música nueva en la pista verde, prueba el sonido, y cuando está listo, enciende las luces de la verde y apaga las de la azul. La gente cruza instantáneamente. Si la música nueva es horrible, vuelve a encender la azul.

Uso práctico

• ✅ Aplicaciones críticas donde el rollback debe ser instantáneo.
• ❌ Sistemas con estado —base de datos compartida— requiere manejar migraciones de esquema compatibles.

Ejemplo trabajado: Blue-Green en AWS

Dos ASG idénticos. El ALB apunta al azul. Deploy a verde, smoke tests. Se actualiza el ALB para apuntar a verde. Si hay problemas, se revierte el ALB a azul. Rollback: 30 segundos, sin re-deploy.

Evidencia

• Blue-Green es una de las estrategias de deploy más antiguas y confiables. AWS CodeDeploy y Kubernetes (con Services y selectors) la soportan.