Despliegues y rollbacks

Qué pasa durante un despliegue

1. Build. Con un repositorio, Railyard construye una imagen en un servidor de build dedicado si tu equipo tiene uno, o si no, en el propio servidor de la app o en un servidor de build temporal que Railyard inicia para el trabajo. Con una fuente image://, en su lugar descarga la imagen; no se construye nada. Consulta Métodos de build.
2. Comando de release. Si la app tiene uno configurado, corre una vez contra la nueva imagen antes de que algo reciba tráfico. Aquí es donde van las migraciones. Si falla, el despliegue se detiene ahí y la app sigue corriendo su versión anterior.
3. Comprobación de estado. El nuevo contenedor arranca junto al que ya está corriendo. Tiene que levantarse y, si la app tiene una ruta de comprobación de estado configurada, responderla dentro del timeout configurado.
4. Cambio de tráfico. Solo cuando el nuevo contenedor pasa la comprobación se mueve el tráfico hacia él. Un despliegue estándar mueve todo el tráfico de una vez; un despliegue canary le envía primero una parte. Consulta Despliegues canary y ventanas de despliegue.
5. La versión anterior se detiene. El contenedor anterior se mantiene corriendo hasta que el nuevo se confirma, y luego se elimina. Esto es lo que hace que los despliegues sean sin downtime: nunca hay un momento en que la app no tenga un contenedor funcional respondiendo.

Si algo falla

Si el build, el comando de release o la comprobación de estado falla, Railyard deja la versión anterior corriendo y marca el despliegue como fallido. Un despliegue malo nunca tumba tu app. La página de despliegue explica qué falló y enlaza a una solución; consulta Solución de problemas en despliegues fallidos.

Hacer un rollback

Hacer un rollback vuelve a desplegar el commit (o imagen) de un release exitoso anterior y restaura las variables con las que corrió. La página de confirmación lista qué variables cambian de vuelta y advierte si un secreto cambió desde ese release. Para conservar las variables actuales y restaurar solo el código, elige code-only (o pásalo como flag/parámetro).

• Panel: en la pestaña Releases & despliegues de la app, elige Roll back to v<n> junto a un release exitoso anterior.
• CLI: railyard releases my-app lista los releases a los que puedes volver; railyard rollback my-app <version> [--code-only].
• API: POST /api/applications/:id/deploys con rollback_to (el id de un despliegue exitoso anterior) y opcionalmente "restore_config": false.

Un rollback es en sí mismo un despliegue: pasa por el mismo build-o-pull, comando de release, comprobación de estado y cambio de tráfico que cualquier otro despliegue, y respeta la ventana de despliegue de la app a menos que la anules. Los releases desplegados antes de que Railyard empezara a guardar una copia de sus variables solo pueden revertir su código.

Historial de releases

Cada despliegue exitoso con un commit se numera como un release (v1, v2, …). La pestaña Releases & despliegues de la app los lista, con los despliegues anteriores a un clic de distancia; railyard deploys --app my-app y GET /api/deploys?application_id=:id muestran el historial completo desde la CLI y la API. Cada despliegue conserva su log, disparador, commit y cualquier nota.

Ver también

• Despliegues canary y ventanas de despliegue — releases con tráfico parcial, despliegues programados y con ventana, notas de despliegue.
• Métodos de build — qué builder corre y cómo encajan los builds en tus servidores.
• Solución de problemas en despliegues fallidos — qué significa cada motivo de fallo y cómo solucionarlo.