El deploy no termina cuando git push acaba: termina cuando estás seguro de que puedes volver atrás en menos de un minuto. La diferencia entre equipos que despliegan a diario con calma y equipos que despliegan viernes a las 18h sudando no es talento — es estrategia elegida conscientemente. Estas son las cuatro, con sus costes reales.
Recreate: la que NO debes usar (pero todos empiezan con ella)
Parar la versión vieja, arrancar la nueva. Cero infraestructura extra, cero complejidad... y cero disponibilidad durante el swap. Aceptable únicamente en hobby projects o sistemas internos con ventanas de mantenimiento. Si tu API atiende clientes reales, sigue leyendo.
Rolling: el estándar de Kubernetes
Desplegar por tandas: 25% de instancias nuevas → verificar salud → siguiente tanda, mientras las viejas drenan tráfico. El servicio nunca deja de responder; la capacidad baja temporalmente (con 4 réplicas y tanda del 25%, operas al 75% durante minutos).
Puntos finos que separan el rolling bien hecho:
- Readiness vs liveness: solo manda tráfico a pods listos (readiness probe), pero reinicia los muertos (liveness). Confundirlos = peticiones a instancias aún calentando.
- Graceful shutdown: al recibir SIGTERM, la instancia vieja debe terminar peticiones en curso antes de morir (
terminationGracePeriodSeconds). Sin esto, errores 502 en cada deploy. - Migraciones compatibles hacia atrás: durante minutos conviven v1 y v2 contra la MISMA base de datos. Toda migración debe ser aditiva (añadir columnas nullable, jamás renombrar/borrar en el mismo paso).
Kubernetes lo hace nativo (strategy: RollingUpdate); Docker Compose exige orquestación manual o herramientas encima.
Blue-Green: dos entornos completos, switch instantáneo
Dos stacks idénticos: blue (producción actual) y green (nueva versión). Despliegas y pruebas green completo —sin tocar producción— y cuando validas, el balanceador cambia todo el tráfico de golpe. Rollback = apuntar a blue otra vez, segundos.
Ventajas honestas:
- Pruebas de humo contra el entorno real ANTES del switch.
- Rollback instantáneo y trivial.
- Mismo estado para todos los usuarios (no mezcla de versiones).
El precio: el doble de infraestructura durante el deploy (o permanente), y el problema heredado de las migraciones: si green requiere esquema nuevo, blue ya no puede funcionar contra esa BD. Patrón de escape: expandir-migrar-contrasar en fases separadas de deploy.
Ideal para: apps medianas en VPS/cloud con presupuesto para duplicar, o donde la consistencia de versión importa más que el ahorro.
Canary: porcentaje progresivo con criterio
Enviar la nueva versión al 1% del tráfico, observar métricas reales (errores, latencia p95, conversiones), subir a 10%, 50%, 100% si nada se degrada. Es la única estrategia que valida con tráfico REAL antes de comprometerse — los canaries detectan problemas que ningún staging replica: carga real, datos raros, patrones de uso inesperados.
Requisitos técnicos serios:
- Enrutamiento por peso (service mesh, ingress controller, o CDN edge).
- Sesiones pegadas si el estado vive en memoria (sticky sessions) o estado externalizado (requisito de todas formas).
- Métricas comparadas automáticamente entre cohorts — mirar dashboards a mano convierte el canary en teatro.
Es la estrategia por defecto de los grandes (Netflix, Google) precisamente porque su volumen hace estadísticamente significativo hasta el 0,1%. Para un SaaS pequeño, un canario del 5% puede tardar horas en acumular señal útil — ahí blue-green suele rendir mejor.
Feature flags: desacoplar deploy de release
La técnica transversal a todas las anteriores: el código nuevo llega desplegado PERO apagado, controlado por una flag evaluada en runtime. El "release" pasa a ser tirar de un interruptor, reversible al instante, sin redeploy.
Casos donde brillan: lanzamientos graduales por cohortes de usuarios, A/B testing, kill switches para features riesgosas, y desacoplar deploys de marketing (código listo lunes, anuncio jueves). El coste: deuda de flags si nadie las limpia — disciplina de borrado obligatoria.
El rollback que nunca ensayaste
Cualquiera de estas estrategias falla si el rollback es teórico. La prueba estándar: una vez al mes, en horario tranquilo, haz rollback REAL de lo último desplegado y cronometra. Dos hallazgos típicos:
- "Rollback" de código es fácil; el de BASE DE DATOS no existe si la migración de ayer fue destructiva. De ahí el mantra: migraciones expansivas primero, contracción semanas después.
- Los artefactos antiguos deben existir: guarda imágenes Docker versionadas y builds precedentes — rollback desde git re-deployando tarda; rollback cambiando tag de imagen son segundos.
Nuestro workflow de GitHub Actions cubre la pieza de automatización (CI + build + publish), y si tu destino es un VPS propio, la guía self-hosting muestra cómo encajan compose y healthchecks en este modelo.
Preguntas frecuentes
¿Cuál elijo para mi proyecto? Heurística rápida: hobby/interno → recreate asumiendo ventana; SaaS pequeño-mediano en cloud → rolling (o blue-green en VPS); producto grande con métricas maduras → canary. Y feature flags siempre que el presupuesto de complejidad lo permita.
¿Zero-downtime real significa cero errores? No: significa sin interrupción de servicio. Errores de la propia v2 llegarán igual — de eso protegen canary y flags, no la topología.
¿Base de datos y deploy van juntos? Nunca en el mismo paso. Regla de oro: cada deploy puede ejecutarse contra la versión anterior del esquema (compatibilidad hacia atrás) — es lo que hace posibles TODAS las estrategias anteriores.
Automatiza tu pipeline de CI/CD con nuestro generador de GitHub Actions, gratis y directamente en tu navegador.