Qué hace que un despliegue sea realmente cero downtime
“Deploy sin downtime” se usa de forma tan suelta que vale la pena ser precisos sobre lo que de verdad exige mecánicamente, no solo lo que promete. No es una sola función —son cinco pasos que todos tienen que cumplirse, en orden, cada vez.
Los cinco pasos
- Build, o pull. Con un repositorio, la imagen nueva se construye en un servidor de build dedicado si el equipo tiene uno, o en el propio servidor de la app o en uno temporal que Railyard arranca para el trabajo. Una fuente
image://se salta el build por completo y simplemente hace el pull. - Comando de release. Si la app tiene uno, corre una vez contra la imagen nueva, antes de que nada reciba tráfico —aquí es donde van las migraciones. Si falla, el despliegue se detiene justo ahí y la app sigue corriendo su versión anterior. Nada de la app en vivo cambió todavía.
- Comprobación de salud. El contenedor nuevo arranca junto al que ya está corriendo, no en su lugar. Si la app tiene configurada una ruta de comprobación de salud, el contenedor nuevo tiene que responderla de verdad dentro del tiempo límite configurado antes de que pase cualquier otra cosa.
- Cambio de tráfico. Solo una vez que el contenedor nuevo pasa su comprobación de salud se le mueve el tráfico —todo de una vez en un despliegue estándar, o una porción a la vez en un deploy canario, vigilado contra la tasa de errores del resto de la app antes de seguir avanzando.
- La versión vieja se detiene. El contenedor anterior sigue corriendo hasta que el nuevo se confirma, y solo entonces se elimina.
Ese orden es el mecanismo completo. Nunca hay un punto entre pasos donde la app tenga cero contenedores funcionales —el viejo no se va hasta que el nuevo ya demostró que funciona.
Qué pasa cuando algo falla
Esta es la parte que de verdad importa más que el camino feliz: si el build, el comando de release o la comprobación de salud fallan, Railyard deja la versión anterior corriendo exactamente como estaba y marca el despliegue como fallido. Un despliegue malo no tira abajo la app —simplemente no sale. La página del despliegue nombra la causa exacta y enlaza al arreglo —mira por qué falla un despliegue en realidad, razón por razón para saber qué significa cada una.
Revertir es el mismo mecanismo, no uno distinto
Un rollback no es una vía de escape con tratamiento especial —es un despliegue del commit o la imagen de un release anterior, lo que significa que pasa exactamente por el mismo build-o-pull, comando de release, comprobación de salud y cambio de tráfico que cualquier otro despliegue. Eso es deliberado: un rollback que se saltara la comprobación de salud sería el único camino de despliegue que de verdad podría causar el downtime que el resto del sistema está construido para evitar.
railyard releases my-app # lista los releases a los que puedes volver
railyard rollback my-app <version> [--code-only]--code-only restaura el código pero mantiene las variables de entorno de hoy —útil cuando un release en sí estaba bien pero una variable cambió desde entonces y no quieres deshacer eso también.
Por qué el orden no se puede saltar
Cada uno de estos pasos existe por un modo de falla específico que cierra. Salta la comprobación de salud y una versión nueva en crash loop recibe tráfico igual. Salta mantener vivo el contenedor viejo durante la comprobación y hay un hueco con nada respondiendo. Corre el comando de release después del cambio en vez de antes y una migración pendiente golpea tráfico en vivo a mitad de camino. Nada de esto es ingeniería exótica —es simplemente no saltarse pasos bajo presión por publicar más rápido.
Detalle completo, incluyendo despliegues canarios y ventanas de despliegue: Despliegues y rollbacks.