Canary despliegues que de verdad vigilan la tasa de error, no solo un timer

Un despliegue estándar es binario: la release nueva pasa su health check y todo el tráfico se mueve a ella de una vez. Eso funciona bien hasta que lo que falla no es un crash al iniciar sino una fuga lenta que solo aparece bajo el 100% de la carga de producción — y para cuando es evidente, todos ya tienen la versión mala. Un canary deploy existe específicamente para ese hueco.

Qué pasa en realidad

Actívalo en Settings → General → Deploy strategy, elige Canary y define un porcentaje de canary (1-99%): ese porcentaje de visitantes nuevos recibe la release nueva, que corre justo al lado de la actual, sin reemplazarla todavía. Una cookie mantiene a cada visitante en la versión que le tocó primero, durante un día — nadie salta entre la versión vieja y la nueva a mitad de sesión.

A partir de ahí, tres configuraciones deciden qué tan cauteloso es el rollout:

• Pasos de rampa, una lista ascendente como 5, 25, 50 — cada paso es su propio canary, vigilado de la misma forma, y completar el último promueve al 100%. Déjalo en blanco para un solo paso que promueves a mano.
• Permanencia por paso, en minutos — déjalo en blanco y promueves cada paso tú mismo; defínelo y Railyard avanza automáticamente en cuanto un paso lleva corriendo ese tiempo sin disparar la siguiente configuración.
• Revertir si la tasa de 5xx supera (%) — la parte que convierte esto en algo más que un simple interruptor de reparto de tráfico. Si la tasa de error de un paso cruza este umbral, Railyard lo revierte solo. Nadie tiene que estar mirando un panel a las 2 a.m. para que esto atrape una release mala.

Mientras está activo, la página de despliegue muestra el número de requests del canary, su tasa de 5xx y su latencia p95 junto a las del resto de la app — la comparación real que decide si se promueve, no una corazonada.

Qué todavía corre como un despliegue estándar

Hay unos pocos casos que siempre se saltan el canary por completo, y conviene conocerlos de entrada para evitar confusiones después: el primer despliegue de una app, un despliegue durante el modo de mantenimiento, una app solo de workers (no hay tráfico que repartir) y una app con un volumen de datos. El comando de release — típicamente las migraciones — igual corre una sola vez, antes de que empiece el canary, lo que significa que las migraciones tienen que funcionar contra el código viejo y el nuevo al mismo tiempo durante todo el tiempo que dure el canary. No es una restricción específica de Railyard; es el trade-off real que hace cualquier sistema de canary despliegues, dicho sin rodeos en vez de disimulado.

Combinarlo con una ventana de despliegue

Canary responde “qué tan rápido llega una release nueva a todos”. Una configuración separada y combinable — las ventanas de despliegue — responde “cuándo se permite que ocurran despliegues, en general”:

railyard deploy-window my-app mon,tue,wed,thu,fri 09:00 17:00 America/Toronto

Los pushes fuera de la ventana se encolan y salen todos juntos cuando se abre; un despliegue manual fuera de ella pregunta primero. Las dos funciones no interactúan más allá de eso — un canary a mitad de rampa cuando se cierra una ventana sigue corriendo exactamente como está configurado, porque avanzar un canary ya iniciado no es la misma acción que iniciar un despliegue nuevo.

Por qué esto importa más cuando eres dueño de los servidores

Un canary con rollback automático es uno de esos lugares donde “self-hosted” podría significar plausiblemente “menos barreras de seguridad que una plataforma administrada” — y esto es la prueba de que no tiene que ser así. El mecanismo es el mismo sin importar quién sea dueño de la máquina: vigilar la tasa de error real contra un umbral real, y dejar que el sistema se proteja solo antes de que una persona tenga que intervenir.

Referencia completa, incluyendo despliegues programados y notas de despliegue: Canary despliegues y ventanas de despliegue.