Despliegue blue-green

El despliegue blue-green mantiene dos ambientes de producción, uno activo y otro en espera; la versión nueva va al que está en espera y luego se cambia todo el tráfico.

La técnica usa dos ambientes equivalentes, llamados blue y green. Uno de ellos atiende a todos los usuarios. La versión nueva se despliega en el otro, donde se puede probar con la configuración de producción y sin tráfico de usuarios. Cuando está lista, se cambia un ajuste en un router, un balanceador o un CDN y todo el tráfico pasa a ese ambiente. El ambiente anterior queda intacto por un tiempo como camino de vuelta.

Ejemplo

Una single-page application se sirve desde un CDN. Cada build se sube a su propia carpeta, como /releases/41/ y /releases/42/. El release 41 está activo. El equipo sube el release 42, corre pruebas de humo contra su URL directa y luego cambia la ruta de origen del CDN para que apunte al release 42. Si algo falla, volver a apuntar al release 41 es un solo cambio de configuración.

Confusión frecuente

En un frontend, el cambio nunca es tan instantáneo como parece desde el servidor. Los usuarios que abrieron la aplicación antes del cambio siguen ejecutando el JavaScript viejo en su pestaña. Cuando navegan, el código viejo puede pedir un chunk con lazy loading que solo existía en el release anterior. Si esos archivos ya no están, la pantalla no carga.

Dos prácticas lo resuelven:

• Mantener disponibles los archivos del release anterior por un tiempo después del cambio.
• Hacer que la API acepte llamadas de las dos versiones del frontend durante esa ventana.

Blue-green cubre los artefactos del frontend. Los cambios de base de datos y los contratos de API necesitan su propio plan de compatibilidad, porque normalmente ambos ambientes los comparten. La guía sobre migrar sin downtime usa la misma idea para los cortes.

Términos relacionados

• Canary release (despliegue canario)
• Rollback (reversión)
• Pipeline de CI/CD