Déploiements et retours arrière

Ce qui se passe pendant un déploiement

1. Build. Pour un dépôt, Railyard construit une image : sur un serveur de build dédié si votre équipe en a un, sinon sur le serveur de l’application ou sur un serveur de build temporaire que Railyard démarre pour l’occasion. Avec une source image://, l’image est récupérée telle quelle; rien n’est construit. Voir Méthodes de build.
2. Commande de release. Si l’application en a une, elle s’exécute une fois sur la nouvelle image avant que quoi que ce soit prenne le trafic : c’est là que vont les migrations. Si elle échoue, le déploiement s’arrête et l’application continue de tourner sur son ancienne version.
3. Test de santé. Le nouveau conteneur démarre à côté de celui qui tourne déjà. Il doit démarrer et, si l’application a un chemin de test de santé configuré, y répondre dans le délai fixé.
4. Bascule du trafic. Le trafic ne bascule vers le nouveau conteneur qu’une fois ce test réussi : un déploiement standard bascule tout le trafic d’un coup; un déploiement canary lui en envoie d’abord une part. Voir Déploiements canary et fenêtres de déploiement.
5. Arrêt de l’ancienne version. L’ancien conteneur reste actif jusqu’à ce que le nouveau soit confirmé, puis il est retiré. C’est ce qui rend les déploiements sans interruption : il n’y a jamais de moment où l’application n’a aucun conteneur qui répond.

En cas d’échec

Si le build, la commande de release ou le test de santé échoue, Railyard laisse l’ancienne version en place et marque le déploiement comme échoué : un mauvais déploiement ne met pas votre application hors service. La page de déploiement explique ce qui a échoué et pointe vers une solution; voir Dépannage des déploiements échoués.

Revenir en arrière

Un retour arrière redéploie le commit (ou l’image) d’une version antérieure réussie 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 cette version. Pour garder les variables actuelles et ne restaurer que le code, choisissez l’option code seulement.

• Tableau de bord : sous l’onglet Releases & deploys de l’application, choisissez Roll back to v<n> à côté d’une version antérieure réussie.
• CLI : railyard releases my-app liste les versions vers lesquelles revenir; railyard rollback my-app <version> [--code-only].
• API : POST /api/applications/:id/deploys avec rollback_to (l’id d’un déploiement réussi antérieur) et, au besoin, "restore_config": false.

Un retour arrière est lui-même un déploiement : il passe par le même build (ou la même récupération d’image), la même commande de release, le même test de santé et la même bascule de trafic que n’importe quel autre déploiement, et respecte la fenêtre de déploiement de l’application sauf si vous la contournez. 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.

Historique des versions

Chaque déploiement réussi avec un commit est numéroté comme une version (v1, v2, …). L’onglet Releases & deploys de l’application les liste, avec les déploiements plus anciens à un clic de distance; railyard deploys --app my-app et GET /api/deploys?application_id=:id donnent l’historique complet depuis la CLI et l’API. Chaque déploiement garde son journal, son déclencheur, son commit et sa note éventuelle.

Voir aussi

• Déploiements canary et fenêtres de déploiement : releases à trafic partiel, déploiements programmés et fenêtres, notes de déploiement.
• Méthodes de build : quel système de build s’exécute et comment les builds s’adaptent à vos serveurs.
• Dépannage des déploiements échoués : ce que signifie chaque raison d’échec et comment la corriger.