Despliegues blue-green: cambiar de versión con una ruta de regreso
Actualizar el mismo servidor que atiende a los usuarios puede introducir una interrupción o dejar una versión parcialmente desplegada. En un despliegue blue-green existen dos entornos: uno sirve producción y el otro recibe la siguiente versión. Los colores identifican roles temporales; no son tecnologías diferentes.
Preparar, comprobar y conmutar
Mientras blue atiende el tráfico, se despliega la nueva versión en green. Se comprueban arranque, salud, dependencias y operaciones representativas mediante una ruta de prueba controlada. Probar el login o un pedido exige tener presentes los efectos sobre datos y servicios externos: un entorno oculto al público no es automáticamente inocuo.
Una vez listo, se cambia el enrutamiento para que las nuevas solicitudes lleguen a green. Puede realizarse mediante un balanceador o una capa de entrada equivalente. Los usuarios mantienen la misma URL pública. Las conexiones persistentes y las peticiones que estaban en curso requieren drenaje y plazos; no debe prometerse cero interrupciones en cualquier situación.
Revertir el tráfico
Conservar blue durante un período permite volver a dirigirle tráfico si aparecen errores. Para tomar la decisión se comparan tasas de fallo, latencia y métricas de negocio, como pedidos completados. Un proceso saludable puede seguir calculando un total incorrecto.
Un cambio total de destino es el patrón básico. Migrar pequeños porcentajes mientras se observa el resultado corresponde a una estrategia gradual, a menudo llamada canary; puede combinarse con dos entornos, pero no es lo mismo que el intercambio completo.
La parte difícil: el esquema de datos
Si green elimina una columna que blue necesita, regresar al ejecutable anterior no restaura la compatibilidad. Compartir base de datos simplifica mantener un único estado, pero obliga a que ambas versiones entiendan el esquema durante la transición.
El patrón expandir y contraer divide la migración: añadir la nueva estructura de manera compatible; desplegar código que soporte la convivencia; migrar o rellenar datos de forma verificable; cambiar las lecturas y escrituras; y eliminar lo antiguo solo cuando ninguna versión activa o recuperable lo necesite. Por ejemplo, renombrar total_price no debe implementarse borrándolo mientras blue todavía lo consulta.
El límite del rollback
Volver al entorno previo revierte qué código atiende las peticiones. No deshace automáticamente pedidos, correos enviados ni cambios persistidos por green. Si los datos nuevos son incompatibles, la recuperación exige una estrategia adicional. La documentación de AWS sobre blue-green trata precisamente la separación de entornos y la necesidad de planificar cambios de datos.
El costo es mantener capacidad duplicada y una disciplina de compatibilidad. La ventaja es poder preparar la versión antes de exponerla y disponer de un mecanismo claro de conmutación, sujeto a verificaciones y a una ventana de reversión definida.