Despliegues sin tiempo de inactividad, paso a paso

Cada despliegue solía venir acompañado de un pequeño ritual de miedo. Alguien elegía una hora tranquila, publicaba un cartel de mantenimiento, cruzaba los dedos y subía el código. Los usuarios veían un indicador de carga o un error, y el equipo contenía la respiración hasta que las comprobaciones de salud volvían a ponerse en verde. Ese modelo es una reliquia. En 2026, tus clientes esperan una aplicación que simplemente esté siempre disponible, y la buena noticia es que el despliegue continuo es un problema resuelto si lo diseñas deliberadamente para ello.

El despliegue sin tiempo de inactividad significa que puedes publicar código nuevo mientras las peticiones siguen fluyendo, sin ventana de mantenimiento y sin conexiones interrumpidas. Tiene menos que ver con una única herramienta ingeniosa y más con un conjunto de hábitos: nunca romper el tráfico en curso, tener siempre una vía de retorno rápida y tratar la base de datos con respeto. Esta guía recorre las estrategias, las partes difíciles (bases de datos, sesiones, comprobaciones de salud) y una lista de verificación que podrás poner en práctica en tu próxima publicación.

Qué requiere realmente "sin tiempo de inactividad"

Antes de elegir una estrategia, conviene nombrar las tres propiedades de las que depende todo despliegue seguro. Descuida cualquiera de ellas y hasta el pipeline de despliegue más sofisticado seguirá perdiendo peticiones.

• Compatibilidad con versiones anteriores. Durante un despliegue, la versión antigua y la nueva de tu código se ejecutan al mismo tiempo. La versión nueva tiene que tolerar los datos escritos por la antigua, y la antigua tiene que sobrevivir junto a la nueva. Si una publicación solo funciona una vez que todo ha cambiado, no tienes cero tiempo de inactividad, tienes una ventana de mantenimiento rápida.
• Apagado ordenado. Cuando retiras una instancia antigua, debe dejar de aceptar nuevas peticiones, terminar las que ya están en curso y luego salir. Una instancia que se mata a mitad de una petición le entrega a tu usuario una respuesta rota por muy elegante que sea el resto de tu pipeline.
• Comprobaciones de salud honestas. Tu load balancer necesita una señal fiable de "esta instancia está lista para servir" y "esta instancia está fallando". Las comprobaciones de salud débiles son el motivo más frecuente de que un despliegue técnicamente correcto provoque una caída de todos modos.

Acierta en estos tres puntos y la estrategia de despliegue se convierte casi en un trámite.

Las estrategias fundamentales

Despliegues rolling

Un despliegue rolling reemplaza las instancias de a pocas cada vez. Retiras una o dos instancias antiguas, levantas el mismo número de nuevas, esperas a que pasen las comprobaciones de salud y luego repites hasta que toda la flota está actualizada. Es la opción por defecto en Kubernetes y en la mayoría de las plataformas de contenedores porque no necesita infraestructura adicional: reutilizas la misma capacidad, simplemente la vas rotando.

La contrapartida es que ambas versiones sirven tráfico real durante todo el despliegue, a veces durante varios minutos. Eso hace que la compatibilidad con versiones anteriores no sea negociable. Las actualizaciones rolling encajan muy bien con servicios sin estado que tienen API limpias y compatibles, y encajan mal cuando un cambio no puede coexistir de forma segura con la versión anterior.

Despliegues blue-green

El blue-green mantiene dos entornos de producción idénticos. El "blue" sirve todo el tráfico mientras despliegas la nueva versión en el entorno "green" inactivo. Haces pruebas de humo sobre green de forma aislada y luego cambias el enrutador para que cada petición vaya a green en un único cambio limpio. El blue permanece caliente e intacto, de modo que si algo parece ir mal, vuelves a él en segundos.

Sus puntos fuertes son un cambio casi instantáneo y una vía de reversión inmediata. El coste es que ejecutas el doble de infraestructura durante la publicación, y aun así tienes que planificar con cuidado los cambios de base de datos porque ambos entornos suelen compartir un único almacén de datos. El blue-green brilla en las publicaciones donde quieres un cambio decisivo y reversible y puedes absorber la capacidad adicional durante una ventana breve.

Despliegues canary

Una publicación canary envía una pequeña porción del tráfico, digamos un 5 por ciento, a la nueva versión mientras todos los demás permanecen en la antigua. Vigilas las tasas de error, la latencia y las métricas de negocio en esa porción. Si los números se mantienen, la amplías al 25, luego al 50 y después al 100 por ciento. Si se degradan, redirecciones la porción de vuelta y casi nadie lo notó.

El canary es la opción más segura para cambios de alto riesgo porque limita el radio de impacto de una mala publicación a una fracción de usuarios. También es la que más te exige: observabilidad en tiempo real, métricas por versión y, en el mejor de los casos, reglas de promoción automatizadas que avancen o reviertan sin que un humano mire fijamente un panel a medianoche. Aquí es donde se encuentran la estrategia de despliegue y las buenas prácticas de observabilidad.

La parte difícil es casi siempre la base de datos

El código de aplicación es fácil de ejecutar en dos versiones a la vez. Los esquemas no lo son, porque solo hay una base de datos y ambas versiones la leen y la escriben en vivo. La técnica que hace esto seguro es el patrón expand and contract, y vale la pena interiorizarlo.

Supongamos que quieres renombrar una columna de full_name a display_name. Hacerlo en una sola migración rompería el código antiguo en el instante en que se ejecutara. En su lugar, repartes el cambio a lo largo de varias publicaciones:

1. Expand. Añade la nueva columna display_name sin eliminar la antigua. Despliega código que escriba en ambas columnas y lea de la antigua. Nada se rompe porque la forma antigua sigue intacta.
2. Migrate. Rellena display_name a partir de full_name para las filas existentes, por lotes para no bloquear la tabla.
3. Transition. Despliega una versión que lea de la nueva columna mientras sigue escribiendo en ambas, y verifícala en producción.
4. Contract. Una vez que ningún código en ejecución dependa de full_name, despliega una publicación que elimine la columna antigua y deje de escribir en ella.

Requiere más publicaciones, pero cada paso es compatible con versiones anteriores, así que el tráfico nunca se rompe. La misma disciplina se aplica a los índices (constrúyelos de forma concurrente para no bloquear las escrituras) y a cualquier cambio que elimine o renombre algo. La regla general: los cambios aditivos son seguros, los cambios destructivos deben esperar hasta que nada dependa de la forma antigua. Este es exactamente el tipo de pensamiento por contrato que abordamos en nuestra guía sobre diseñar API que los desarrolladores adoran, y es el mismo reflejo aplicado a tu capa de datos.

Sesiones, conexiones y apagado ordenado

Dos detalles más separan un despliegue fluido de uno tosco.

Primero, no ancles el estado del usuario a una instancia específica. Si las sesiones viven en memoria en un solo servidor, retirar ese servidor cierra la sesión de esos usuarios. Mantén el estado de sesión en un almacén compartido como Redis, o usa tokens sin estado, para que cualquier instancia pueda servir a cualquier usuario y retirar una instancia sea invisible.

Segundo, drena las conexiones correctamente. Cuando se le indica a una instancia que se apague, debe fallar de inmediato su comprobación de disponibilidad para que el load balancer deje de enviarle nuevas peticiones, seguir sirviendo las que están en curso hasta completarlas y solo entonces terminar. En Kubernetes esto es el hook preStop más un valor sensato de terminationGracePeriodSeconds. Sin ello, perderás exactamente las peticiones que estaban en curso cuando murió el pod antiguo, y esos fallos son exasperantes de reproducir porque solo ocurren durante los despliegues.

Los feature flags desacoplan el despliegue de la publicación

Uno de los hábitos de mayor apalancamiento en la entrega moderna es separar el desplegar código del publicar una funcionalidad. Envía el código nuevo en modo oscuro, envuelto en un feature flag que está desactivado en producción. El código está en vivo, ejercitado por tu infraestructura, pero invisible para los usuarios. Cuando estás listo, activas el flag para encender la funcionalidad, y si se comporta mal lo vuelves a desactivar sin un nuevo despliegue.

Esto convierte una publicación aterradora en dos eventos de bajo riesgo. También se combina de maravilla con la lógica canary: activa el flag primero para usuarios internos, luego para el 1 por ciento de los clientes y después para todos. El pipeline de despliegue saca el código de forma segura, y el flag controla la exposición según tu propio calendario.

Tu lista de verificación de despliegue sin tiempo de inactividad

Úsala antes y durante una publicación. Recoge las salvaguardas que más importan.

1. Confirma la compatibilidad con versiones anteriores. Verifica que la nueva versión tolera los datos y las llamadas de API de la antigua, y viceversa.
2. Divide los cambios de esquema arriesgados. Aplica el patrón expand and contract para que cada paso de migración sea aditivo y reversible.
3. Externaliza el estado. Asegúrate de que las sesiones y las cachés vivan en un almacén compartido, no en la memoria de la instancia.
4. Cablea comprobaciones de salud reales. Separa la disponibilidad (listo para el tráfico) de la vitalidad (aún vivo) para que el load balancer enrute correctamente.
5. Habilita el apagado ordenado. Configura el drenaje de conexiones y un periodo de gracia de apagado lo bastante largo para terminar las peticiones en curso.
6. Elige la estrategia según el cambio. Rolling para actualizaciones rutinarias sin estado, blue-green para cambios decisivos y reversibles, canary para cambios de alto riesgo.
7. Despliega detrás de un flag. Envía en modo oscuro y controla la exposición por separado del despliegue.
8. Vigila las métricas correctas. Sigue la tasa de error, la latencia y una métrica de negocio clave por versión durante y después del despliegue.
9. Ensaya la reversión. Conoce el comando o el interruptor exacto para revertir, y confirma que funciona antes de necesitarlo bajo presión.
10. Automatiza el pipeline. Integra estas barreras en el CI/CD para que la vía segura sea la única vía, no una lista de verificación que alguien podría saltarse.

Ese último punto es la diferencia entre hacer esto una vez y hacerlo cada día. Según nuestra experiencia, los equipos que automatizan la promoción y la reversión publican mucho más a menudo con muchos menos incidentes, porque la disciplina vive en el pipeline en lugar de en la memoria de alguien a las 2 de la madrugada.

Cómo puede ayudar Innovation T

El despliegue sin tiempo de inactividad es una capacidad que construyes, no un interruptor que accionas. Toca tu arquitectura, tus hábitos de base de datos, tu pipeline de CI/CD y tu stack de observabilidad, y las piezas tienen que encajar entre sí. Ese es el tipo de trabajo que nuestro equipo hace cada semana.

En Innovation T, ayudamos a los equipos a diseñar pipelines de despliegue que publican de forma segura y frecuente: despliegues blue-green y canary, estrategias de migración expand-and-contract, infraestructura de feature flags, y las comprobaciones de salud y el monitoreo que lo hacen todo confiable. Si tus servicios siguen fuertemente acoplados, nuestra guía sobre pasar de un monolito a microservicios muestra la base que hace posibles, en primer lugar, las publicaciones independientes y sin tiempo de inactividad.

Si un despliegue todavía significa una página de mantenimiento o una respiración contenida, déjanos cambiar eso. Explora nuestros servicios o ponte en contacto y te ayudaremos a construir un proceso de publicación que tus usuarios nunca noten.