Un despliegue no termina cuando el contenedor arranca
Existe una clase específica de bug de despliegue que es casi imposible de depurar después de que pasa: el despliegue reporta éxito, el contenedor está sano, y aun así, por un rato, los requests devuelven 502. Para cuando alguien lo revisa, todo está bien.
La causa suele estar en la brecha entre que un contenedor esté listo y que tu app sea realmente alcanzable en su URL real.
Dos preguntas distintas
“¿Está arriba el contenedor?” es una pregunta útil, y Railyard la hace antes de dejar que una versión nueva reciba tráfico. Pero no es la pregunta que hacen tus usuarios. Ellos llegan a tu aplicación por su dominio real, por HTTPS, y ese camino tiene su propio momento de ponerse al día después de un release.
Así que un despliegue de Railyard revisa las dos cosas: la versión nueva tiene que responder por su cuenta primero, y después tiene que ser realmente alcanzable de la forma en que llegaría un visitante, antes de que el despliegue se marque como terminado.
Qué pasa si no lo es
Si la versión nueva nunca se pone sana, nada se mueve: la versión vieja sigue sirviendo, el contenedor nuevo se elimina, y el despliegue se marca como fallido con la razón, incluyendo las propias líneas de log de la versión nueva para que veas por qué no se levantó.
Si la versión nueva está sana pero nunca se vuelve alcanzable en la URL real dentro de unos minutos, Railyard revierte por su cuenta: la versión anterior se arranca de nuevo y el despliegue se marca como fallido con la razón, en vez de dejar una app a medio cambiar.
El resultado
El punto de todo esto no es el despliegue en sí. Un despliegue que termina significa que la URL funciona, y un error en tus logs después significa que de verdad hay algo mal con tu aplicación, no un resto del release anterior. Eso es lo que hace que valga la pena confiar en los despliegues sin downtime en vez de solo tener esperanza.