Despliegues canary y ventanas de despliegue

Estos son los controles para cuándo y cómo un release sale a producción. Todos están en la página de la app y en la API; la mayoría también en la CLI.

Despliegues canary

Un despliegue estándar mueve todo el tráfico al nuevo release en cuanto pasa su comprobación de disponibilidad. Un despliegue canary corre el nuevo release junto al actual y le envía primero solo una parte del tráfico.

Actívalo: app → Configuración → General → Estrategia de despliegue. Elige Canary y configura:

• Porcentaje canary (%): 1–99. Ese porcentaje de visitantes nuevos recibe el nuevo release. Una cookie mantiene a cada visitante en la versión que recibió primero, por un día.
• Pasos de rampa (%): una lista ascendente opcional, por ejemplo 5, 25, 50. Cada paso corre como su propio canary con el mismo rollback automático de abajo; una vez que el último paso pasa, promover lo lleva al 100%. Déjalo en blanco para un solo paso, y luego promueve manualmente.
• Permanencia por paso (minutos): déjalo en blanco para promover cada paso manualmente. De lo contrario, Railyard avanza al siguiente paso, o promueve el último, por su cuenta después de esos minutos.
• Hacer rollback si la tasa de 5xx supera (%): si la tasa de error de un paso supera esto, Railyard lo revierte.

Mientras un canary está activo, la página de la app muestra un banner. La página de despliegue compara las solicitudes, la tasa de 5xx y la latencia p95 del canary con el resto de la app, y tiene Promover (envía el 100% al nuevo release, o inicia el siguiente paso de rampa) y Hacer rollback.

Cosas que debes saber:

• El comando de release, como tus migraciones, corre antes de que inicie el canary, así que las migraciones deben funcionar con ambas versiones.
• Los workers y cualquier servidor adicional mantienen el release actual hasta que promuevas.
• El primer despliegue de una app, un despliegue durante el modo de mantenimiento, una app solo de workers y una app con un volumen de datos siempre usan un despliegue estándar.

API: PATCH /api/applications/:id/deploy_strategy (deploy_strategy, canary_percent, canary_steps_text — separados por comas, por ejemplo "5, 25, 50" — canary_promote_after_minutes, canary_max_error_rate), luego POST /api/deploys/:id/canary/promote o DELETE /api/deploys/:id/canary. Todavía no hay un comando de CLI para canaries.

Ventanas de despliegue

Una ventana de despliegue define los días, horas y zona horaria en los que una app puede desplegar. Configúrala en Configuración → General → Ventana de despliegue.

• Los push y auto-despliegues fuera de la ventana esperan, y salen como un solo despliegue cuando la ventana se abre.
• Un despliegue manual fuera de la ventana pregunta primero, y puedes desplegar de todas formas.
• Un rollback fuera de la ventana despliega de todas formas, con una advertencia en la página de confirmación.
• Una ventana que termina antes de empezar corre durante la noche (22:00–02:00). Desmarca todos los días para permitir despliegues en cualquier momento.

railyard deploy-window my-app mon,tue,wed,thu,fri 09:00 17:00 America/Toronto
railyard deploy-window my-app off
railyard deploy my-app --anyway          # outside the window

API: PATCH /api/applications/:id/deploy_window con days, start, end y time_zone. "days": [] elimina la ventana.

Despliegues programados

Elige una hora y el despliegue inicia entonces. La hora debe caer dentro de la ventana de despliegue, si la app tiene una. Puedes cancelar un despliegue programado, en cola o en ejecución.

railyard deploy my-app --at 2026-10-02T14:00:00Z --message "pricing page"
railyard deploy:cancel 482

API: POST /api/applications/:id/deploys con at (ISO 8601), y POST /api/deploys/:id/cancel.

Notas de despliegue

Agrega una nota de hasta 500 caracteres a un despliegue manual o a un rollback. Se muestra en las listas de despliegues, en la página de despliegue, en el registro de actividad, en las notificaciones y en los webhooks deploy.*. Un despliegue reintentado conserva su nota.

railyard deploy my-app --message "hotfix for checkout"

Los rollbacks restauran las variables

Hacer un rollback vuelve a desplegar el commit de ese release y restaura las variables con las que corrió. La página de confirmación lista las variables que cambian de vuelta y advierte si un secreto cambió desde entonces. Para revertir el código y conservar las variables actuales:

railyard rollback my-app 471 --code-only --message "roll back, keep new keys"

Los releases desplegados antes de que Railyard guardara una copia de sus variables solo pueden revertir su código.

Despliega una rama, tag o commit una sola vez

Opciones de despliegue… en la página de la app, railyard deploy my-app --ref v2.1.0, o ref en la API despliega otra rama, tag o commit una sola vez. La rama que la app rastrea no cambia.

Git pushes estrictos

Con git push railyard main (consulta CLI), un push espera el build por defecto. Un build que falla rechaza el push, así que la rama conserva su commit anterior. Desactiva esto en Configuración → General o con railyard git:strict my-app off.