Deployar es más que subir archivos
Cuando tu aplicación ya tiene tráfico real, la pregunta deja de ser "¿cómo subo el código?" y pasa a ser "¿cómo lo sustituyo sin cortar el servicio ni arriesgar una catástrofe?". Existen varias estrategias probadas, cada una con un equilibrio distinto entre complejidad, coste y seguridad. Conocerlas te permite elegir conscientemente en lugar de depender siempre de la misma receta.
Blue-green: dos entornos, un interruptor
Mantienes dos entornos idénticos en producción, llamados tradicionalmente blue y green. En cualquier momento, solo uno sirve tráfico real. El despliegue funciona así:
- Mientras blue atiende a los usuarios, instalas la versión nueva en green.
- Haces pruebas contra green en privado (smoke tests, health checks).
- Cuando estás conforme, el balanceador conmuta todo el tráfico de blue a green.
- Blue queda como respaldo. Si algo sale mal, vuelves a conmutar en segundos.
Ventajas
- Rollback instantáneo: volver atrás es un cambio de switch, no un redeploy.
- Zero downtime: los usuarios no perciben el cambio.
- Testeo previo real: pruebas contra infraestructura de producción antes de abrir la puerta.
Desventajas
- Coste doble: mantienes dos entornos funcionando a la vez.
- Migraciones de base de datos: si hay cambios de esquema, ambos entornos deben convivir con él. Requiere planificación.
Rolling update: reemplazo gradual
En lugar de duplicar infraestructura, reemplazas instancias una por una. Si tienes diez servidores, actualizas uno, esperas a que pase los health checks, sigues con el siguiente. Durante el proceso conviven dos versiones en producción. Es la estrategia por defecto en Kubernetes y en la mayoría de orquestadores modernos.
Ventajas
- Sin doblar recursos: usas la infraestructura que ya tienes.
- Automatización natural: los orquestadores lo implementan de serie.
- Buen punto medio: si un nodo falla al arrancar la versión nueva, el despliegue se detiene antes de tocar al resto.
Desventajas
- Compatibilidad entre versiones: durante el rolling, clientes y servidores viejos y nuevos coexisten. Tus APIs deben tolerarlo.
- Rollback más lento: revertir requiere otro rolling, no un switch.
Canary: suelta al canario primero
El nombre viene de los canarios que los mineros llevaban a las minas para detectar gases tóxicos. La idea es análoga: envías un porcentaje pequeño del tráfico (por ejemplo, el 5%) a la versión nueva, observas métricas y solo sigues escalando si todo va bien. Si el error rate sube o la latencia empeora, retiras el canary antes de que el impacto sea general.
Ventajas
- Detección temprana: bugs que solo aparecen bajo carga real se ven con pocos usuarios afectados.
- Control fino: puedes segmentar por región, tipo de usuario o dispositivo.
- Menor blast radius: un fallo grave impacta al 5%, no al 100%.
Desventajas
- Requiere observabilidad seria: si no mides bien, no sabes si tu canary va bien o mal.
- Infraestructura más compleja: el balanceador debe saber enrutar por porcentajes.
Cuál elegir según tu contexto
No hay una estrategia universalmente mejor. Depende de tres factores: tamaño del equipo, tolerancia al riesgo y presupuesto de infraestructura.
- Equipo pequeño, proyecto medio: rolling update suele ser suficiente. Lo obtienes gratis con cualquier orquestador moderno.
- Equipo que necesita rollback instantáneo: blue-green. La seguridad compensa el coste duplicado.
- Equipo con tráfico alto y observabilidad madura: canary. Es la estrategia más segura, pero exige métricas, alertas y automatización avanzada.
Muchos equipos combinan estrategias: canary para la primera oleada y luego rolling para el resto. Lo importante es que la decisión sea consciente y documentada, no una costumbre heredada. Cada despliegue es una oportunidad de cerrar la puerta al siguiente incidente.
