Déploiements canary et fenêtres de déploiement

Voici les commandes qui déterminent quand et comment une version passe en production. Elles se trouvent toutes sur la page de l’application et dans l’API; la plupart sont aussi dans la CLI.

Déploiements canary

Un déploiement standard bascule tout le trafic vers la nouvelle version une fois qu’elle réussit son test de disponibilité. Un déploiement canary fait tourner la nouvelle version à côté de l’actuelle et ne lui envoie d’abord qu’une partie du trafic.

Activez-le : application → Settings → General → Deploy strategy. Choisissez Canary et configurez :

• Canary share (%) : de 1 à 99. Cette part des nouveaux visiteurs reçoit la nouvelle version. Un témoin garde chaque visiteur sur la version qu’il a reçue en premier, pendant une journée.
• Ramp steps (%) : une liste croissante optionnelle, par exemple 5, 25, 50. Chaque palier tourne comme son propre canary, avec le même retour arrière automatique décrit plus bas; une fois le dernier palier franchi, la promotion l’envoie à 100 %. Laissez-le vide pour un seul palier, puis faites la promotion manuellement.
• Dwell per step (minutes) : laissez-le vide pour promouvoir chaque palier manuellement. Sinon, Railyard passe seul au palier suivant, ou promeut le dernier, après ce nombre de minutes.
• Roll back above 5xx rate (%) : si le taux d’erreur d’un palier dépasse cette valeur, Railyard revient en arrière.

Pendant qu’un canary est actif, la page de l’application affiche une bannière. La page de déploiement compare les requêtes, le taux 5xx et la latence p95 du canary avec le reste de l’application, et propose Promote (envoie 100 % à la nouvelle version, ou lance le palier suivant) et Roll back.

Choses à savoir :

• La commande de release, comme vos migrations, s’exécute avant le démarrage du canary; les migrations doivent donc fonctionner avec les deux versions.
• Les workers et tout serveur additionnel gardent la version actuelle jusqu’à ce que vous fassiez la promotion.
• Le premier déploiement d’une application, un déploiement pendant le mode maintenance, une application composée uniquement de workers et une application avec un volume de données utilisent toujours un déploiement standard.

API : PATCH /api/applications/:id/deploy_strategy (deploy_strategy, canary_percent, canary_steps_text, séparés par des virgules, par exemple "5, 25, 50", canary_promote_after_minutes, canary_max_error_rate), puis POST /api/deploys/:id/canary/promote ou DELETE /api/deploys/:id/canary. Il n’y a pas encore de commande CLI pour les canaries.

Fenêtres de déploiement

Une fenêtre de déploiement définit les jours, les heures et le fuseau horaire pendant lesquels une application peut être déployée. Configurez-la sous Settings → General → Deploy window.

• Les push et les déploiements automatiques hors de la fenêtre attendent, et partent comme un seul déploiement à l’ouverture de la fenêtre.
• Un déploiement manuel hors de la fenêtre demande une confirmation d’abord, et vous pouvez déployer malgré tout.
• Un retour arrière hors de la fenêtre se déploie malgré tout, avec un avertissement sur la page de confirmation.
• Une fenêtre qui se termine avant son heure de début s’étend sur la nuit (22 h–2 h). Décochez tous les jours pour permettre les déploiements à toute heure.

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 avec days, start, end et time_zone. "days": [] supprime la fenêtre.

Déploiements programmés

Choisissez une heure et le déploiement démarre à ce moment. L’heure doit tomber dans la fenêtre de déploiement, si l’application en a une. Vous pouvez annuler un déploiement programmé, en file d’attente ou en cours.

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

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

Notes de déploiement

Ajoutez une note de 500 caractères maximum à un déploiement manuel ou à un retour arrière. Elle apparaît dans les listes de déploiements, sur la page de déploiement, dans le journal d’activité, dans les notifications et dans les webhooks deploy.*. Un déploiement relancé garde sa note.

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

Le retour arrière restaure aussi les variables

Faire un retour arrière redéploie le commit de cette version et restaure les variables avec lesquelles elle tournait. La page de confirmation liste les variables qui reviennent en arrière et avertit si un secret a changé depuis. Pour revenir en arrière sur le code seulement et garder les variables actuelles :

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

Les versions déployées avant que Railyard ne conserve une copie de leurs variables ne peuvent revenir en arrière que sur leur code.

Déployer une branche, une étiquette ou un commit une seule fois

Deploy options… sur la page de l’application, railyard deploy my-app --ref v2.1.0, ou ref dans l’API déploie une autre branche, étiquette ou commit une seule fois. La branche suivie par l’application ne change pas.

Push git stricts

Avec git push railyard main (voir CLI), un push attend par défaut la fin du build. Un build qui échoue rejette le push, donc la branche garde son ancien commit. Désactivez ceci sous Settings → General ou avec railyard git:strict my-app off.