Des déploiements canary qui surveillent vraiment le taux d'erreur, pas juste une minuterie

Un déploiement standard est binaire : la nouvelle version passe son contrôle de santé, et tout le trafic bascule vers elle d’un coup. C’est très bien jusqu’à ce que ce qui casse ne soit pas un plantage au démarrage mais une fuite lente qui n’apparaît que sous 100 % de la charge de production — le temps que ce soit évident, tout le monde a déjà la mauvaise version. Un déploiement canary existe précisément pour cet écart.

Ce qui se passe vraiment

Activez-le sous Settings → General → Deploy strategy, choisissez Canary, et définissez une part canary (1-99 %) : ce pourcentage de nouveaux visiteurs reçoit la nouvelle version, qui tourne juste à côté de l’actuelle, sans la remplacer encore. Un cookie garde chaque visiteur sur la version qu’il a reçue en premier, pendant une journée — personne ne rebondit entre l’ancienne et la nouvelle en plein milieu d’une session.

À partir de là, trois réglages décident à quel point le déploiement progressif est prudent :

• Ramp steps, une liste ascendante comme 5, 25, 50 — chaque étape est son propre canary, surveillée de la même façon, et terminer la dernière promeut à 100 %. Laissez vide pour une seule étape que vous promouvez vous-même.
• Dwell per step, en minutes — laissez vide et vous promouvez chaque étape vous-même; définissez-le et Railyard avance automatiquement une fois qu’une étape a tourné assez longtemps sans déclencher le réglage suivant.
• Roll back above a 5xx rate (%) — la partie qui fait que c’est plus qu’un simple interrupteur de répartition de trafic. Si le taux d’erreur d’une étape dépasse ce seuil, Railyard la retire tout seul. Personne n’a besoin de surveiller un tableau de bord à 2 h du matin pour que ça attrape une mauvaise version.

Pendant qu’il est en direct, la page de déploiement montre le nombre de requêtes du canary, son taux de 5xx et son temps de réponse p95 à côté de ceux du reste de l’application — la vraie comparaison qui décide de promouvoir ou non, pas une impression.

Ce qui doit encore tourner comme un déploiement standard

Quelques cas sautent toujours complètement le canary, et les connaître d’avance évite la confusion plus tard : le tout premier déploiement d’une application, un déploiement en mode maintenance, une application uniquement worker (rien à qui répartir le trafic), et une application avec un volume de données. La commande de release — les migrations, typiquement — tourne quand même une fois, avant que le canary ne démarre, ce qui veut dire que les migrations doivent fonctionner contre l’ancien et le nouveau code en même temps pendant toute la durée du canary. Ce n’est pas une contrainte propre à Railyard; c’est le vrai compromis que fait tout système de déploiement canary, dit clairement plutôt qu’enjolivé.

Le combiner avec une fenêtre de déploiement

Canary répond à « à quelle vitesse une nouvelle version atteint tout le monde ». Un réglage séparé et composable — les fenêtres de déploiement — répond à « quand les déploiements sont-ils permis du tout » :

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

Les push en dehors de la fenêtre s’accumulent et sortent ensemble quand elle s’ouvre; un déploiement manuel en dehors demande d’abord confirmation. Les deux fonctionnalités n’interagissent pas au-delà de ça — un canary en pleine montée quand une fenêtre se ferme continue exactement comme configuré, puisque faire progresser un canary déjà démarré n’est pas la même action que démarrer un nouveau déploiement.

Pourquoi ça compte plus une fois qu’on possède les serveurs

Un canary avec retrait automatique est un des endroits où « auto-hébergé » pourrait plausiblement vouloir dire « moins de garde-fous qu’une plateforme gérée » — et c’est la preuve que ce n’est pas obligé. Le mécanisme est le même peu importe qui possède la machine : surveiller le vrai taux d’erreur contre un vrai seuil, pas une minuterie fixe, et laisser le système se protéger avant qu’un humain n’ait à le faire.

Référence complète, incluant les déploiements programmés et les notes de déploiement : Déploiements canary et fenêtres de déploiement.