Qué es blue-green y cuándo usarlo
Blue-green mantiene dos entornos idénticos: uno activo (por ejemplo, azul) recibiendo todo el tráfico, y otro (verde) donde despliegas la nueva versión y la pruebas antes de conmutar el tráfico en el balanceador o el ingress. Si algo falla, vuelves al entorno anterior en un solo comando, sin reconstruir nada. Es la estrategia adecuada cuando el riesgo de un cambio es binario: o funciona bien o hay que revertir de inmediato, sin fase intermedia de observación gradual.
- Dos entornos idénticos, conmutación en balanceador o ingress
- Rollback en un comando, sin reconstrucción
- Pruebas de humo automáticas antes de conmutar el tráfico
Buenas prácticas que aplicamos
El mayor riesgo de un despliegue sin downtime no es la conmutación en sí, es lo que pasa con la base de datos entre versiones. Tratamos cada despliegue con la misma disciplina, sin atajos por prisa de lanzar una función a tiempo, y te acompañamos la primera vez que aplicas el patrón expand-and-contract para que no sea una sorpresa a mitad de un lanzamiento.
- Nunca desplegamos migraciones que rompen el esquema junto con el código
- Pruebas de humo automáticas antes de conmutar el tráfico
- Rollback documentado en un solo comando
- El entorno anterior se mantiene activo hasta que las métricas están verdes
- Ventanas de despliegue alineadas con el horario laboral de tu negocio
Canary cuando el cambio es progresivo
Canary manda un porcentaje pequeño del tráfico a la nueva versión y lo va ampliando según las métricas se mantengan dentro de lo esperado: tasa de error, latencia, conversión. Es la estrategia adecuada cuando quieres validar el impacto real con usuarios reales antes de comprometer todo el tráfico, especialmente en cambios donde el impacto no es evidente solo con pruebas automatizadas. Combinamos canary con feature flags cuando el cambio afecta a la lógica de negocio, no solo a la infraestructura.
- Porcentaje de tráfico creciente, con métricas que deciden avanzar o revertir
- Feature flags para cambios en la lógica de negocio
- Rollback automático si las métricas se degradan
Migraciones de base de datos: la parte que suele romper
Con dos versiones del código corriendo a la vez, la base de datos tiene que ser compatible con ambas. Usamos el patrón expand/contract: primero añades la columna o tabla nueva sin quitar la antigua (expand), despliegas el código que usa ambas, y solo cuando la versión antigua deja de recibir tráfico eliminas lo que sobra (contract). Nunca desplegamos una migración que rompe el esquema en el mismo paso que el código nuevo.
Cada suscripción incluye horas mensuales de DevOps, CyberSecurity y Programación: 1 h desde el plan cPanel Advanced, 1–8 h en VPS, entre 5 y 10 h en servidores dedicados según el plan y 10 h en servidores GPU. Las horas se solicitan desde el panel de cliente, no se acumulan al mes siguiente, y lo que supera la cuota se acepta y se factura por separado.
