Orbit
Restauration d'un déploiement
If a deployment breaks production, you can put an earlier build back in front of traffic in seconds without rebuilding anything. This guide covers how rollback works, how to pick the right…
Si un déploiement casse la production, vous pouvez remettre en service une version antérieure en quelques secondes sans tout reconstruire. Ce guide explique comment fonctionne la restauration, comment choisir le bon déploiement, les restaurations automatiques qu'Orbit peut effectuer pour vous, et ce qu'il faut faire après une restauration.
Comment fonctionne la restauration
Orbit conserve l'artefact empaqueté de chaque build réussi. Une restauration ne relance pas votre installation ni votre commande de build : elle promeut un artefact qui existe déjà et a déjà été servi, donc elle se termine en quelques secondes et ne peut échouer pour aucune des raisons pour lesquelles un build peut échouer.
C'est précisément pour cela qu'il faut y recourir en priorité. La restauration est plus rapide et bien plus prévisible que d'essayer de corriger en avant pendant que votre site est en panne.
Restaurer à un déploiement antérieur
- Ouvrez votre projet dans Orbit.
- Ouvrez l'onglet Deployments.
- Trouvez le dernier déploiement que vous savez être bon.
- Cliquez sur Roll back dans cette ligne et confirmez.
La confirmation indique exactement ce qui se passera : le trafic sera servi à partir du build plus ancien immédiatement, et le déploiement actuel sera remplacé.
Vous pouvez aussi restaurer à partir de la page de détail du déploiement, où le bouton lit Rollback to suivi du hash de commit court.
Le déploiement restauré reçoit le badge CURRENT. Le déploiement dont vous vous éloignez reste dans l'historique avec le statut Rolled back.
La restauration n'est pas destructrice et n'a pas besoin d'être annulée. Rien n'est supprimé, aucun historique n'est réécrit, et votre dépôt reste intact. Votre prochain push réussi vers la branche de production devient simplement la nouvelle version en direct de la façon normale.
Identifier le bon déploiement
Chaque ligne de l'onglet Deployments affiche le message de commit et le hash court, la branche, le statut, quand il s'est déployé, et qui l'a poussé. Celui en direct porte le badge CURRENT.
Habituellement, vous voulez le déploiement immédiatement avant celui qui a causé le problème. Deux choses vous aident à en être sûr :
- Compare. Ouvrez le déploiement suspect et cliquez sur Compare pour voir les différences avec le précédent : temps de build, taille de l'artefact, état du cache, framework, et différence au niveau des fichiers de l'artefact.
- Deployment notes. Tout déploiement peut porter une note d'jusqu'à 500 caractères. Ajouter "hotfix for payment bug" ou "feature flag X on" au moment du déploiement ne coûte rien et rend l'historique lisible des mois plus tard, c'est-à-dire exactement quand vous en avez besoin.
Restaurer à un artefact ne restaure pas vos variables d'environnement, règles de redirection ou en-têtes de réponse. Ceux-ci sont lus au moment de la requête ou du build, pas intégrés à l'artefact. Si l'incident a été causé par une modification de configuration plutôt qu'une modification de code, restaurer le code ne le fixera pas. La page de détail du déploiement compare les variables injectées au moment du build avec votre configuration actuelle, ce qui est le moyen le plus rapide de les distinguer.
Restauration automatique
Orbit peut le faire pour vous avant même que vous l'ayez remarqué. Les trois paramètres sont dans Settings.
Auto-Rollback en cas d'échec
Sous Runtime, activez Auto-rollback on failure. Si un déploiement de production échoue, le dernier déploiement sain est restauré automatiquement et les visiteurs ne voient aucun temps d'arrêt. Staging a son propre curseur équivalent.
Health Check
Sous Health check, définissez un Health check path, par exemple / ou /api/health. Après chaque déploiement de production, Orbit récupère ce chemin. S'il ne retourne pas une réponse 2xx dans les 15 secondes, le déploiement sain précédent est restauré.
Smoke Tests
Sous Smoke tests, listez jusqu'à 10 chemins séparés par des virgules, par exemple /,/blog,/api/health. Après chaque déploiement réussi, Orbit envoie un GET à chacun et enregistre réussi ou échoué. Si l'un échoue et que la restauration automatique est activée, le déploiement précédent est restauré. Le résultat apparaît sur la page de déploiement comme Smoke tests passed ou un décompte d'échecs, et dit Triggered rollback quand il en a causé un.
Un health check sur une route qui exerce réellement votre base de données vaut bien plus qu'un sur la page d'accueil. Un déploiement cassé qui sert toujours une page d'accueil en cache réussira un contrôle / et échouera un vrai.
Restauration contre verrou de déploiement
Si vous n'êtes pas prêt à restaurer mais que vous voulez arrêter tout nouveau déploiement en direct pendant que vous enquêtez, verrouillez plutôt les déploiements :
- Ouvrez le projet.
- Cliquez sur Lock deploys.
- Ajoutez une raison, par exemple "investigating production issue".
Les déploiements déclenchés par des poussées sont alors silencieusement ignorés, et une bannière lit Production deploys are locked avec votre raison. Les déploiements manuels fonctionnent toujours, c'est délibéré : le verrou arrête les déploiements accidentels, pas la correction que vous expédiez. Cliquez sur Unlock deploys pour le lever.
Un verrou et une restauration fonctionnent bien ensemble. Restaurez d'abord pour rétablir le service, puis verrouillez pour que la fusion de routine de personne ne l'annule pendant que vous diagnostiquez.
Promouvoir Staging en Production
Si vous exécutez un environnement de staging, vous pouvez mettre un build staging testé en production sans rien pousser.
- Ouvrez l'aperçu du projet et trouvez la section Staging.
- Si staging est en avance sur la production, Promote to production apparaît.
- Cliquez dessus et confirmez.
Lisez la confirmation attentivement, car il y a deux comportements de promotion différents dans Orbit et ils ne sont pas interchangeables. Promouvoir à partir de l'aperçu du projet déclenche un fresh production build at the same commit, utilisant les variables d'environnement de production et les commandes de build de production. L'artefact de staging n'est pas réutilisé. Promouvoir un déploiement de staging spécifique à partir de sa page de détail indique clairement que le build de staging monte en direct immédiatement sans reconstruction. Si vos variables d'environnement de staging et de production diffèrent, le premier chemin produira un artefact différent de celui que vous avez testé.
Orbit peut aussi promouvoir pour vous. Auto-promote staging dans Settings promeut le staging en production après un nombre d'heures de staging sain avec smoke tests réussissant, vérifié tous les 15 minutes.
Après une restauration
Corrigez le problème sous-jacent dans votre dépôt et poussez un nouveau commit. Cela déclenche un build normal qui devient la nouvelle version en direct. Si vous avez verrouillé les déploiements, déverrouillez-les d'abord, ou la poussée sera ignorée.
L'onglet Activity du projet enregistre la restauration avec tout le reste qui s'est passé, donc il y a une piste d'audit de qui a restauré quoi et quand.
Ce qui limite la distance à laquelle vous pouvez remonter
La restauration a besoin que l'artefact existe toujours. Deux paramètres contrôlent cela :
- La fenêtre d'historique de déploiement de votre plan : 7 jours sur Launch, 30 sur Liftoff, 90 sur Apex.
- Le paramètre Artifact retention du projet, qui conserve un nombre d'artefacts réussis par environnement, de 10 à 500, par défaut 50.
L'artefact du déploiement actuellement en direct est toujours conservé indépendamment de l'un ou l'autre.
Si vous déployez plusieurs fois par jour, le décompte d'artefacts est la limite que vous atteindrez en premier, pas le décompte de jours. Cinquante déploiements peuvent être une seule semaine. Augmentez Artifact retention plutôt que de découvrir le plafond pendant un incident.