Retour arrière
Le déploiement d'avant revient en 4 secondes
Savoir qu'une page est cassée est la moitié du travail. L'autre moitié, c'est la réparer avant d'avoir compris pourquoi : le déploiement précédent marchait, il suffit d'y revenir.
« Je savais que c'était cassé, mais j'étais dans le train. »
Une alerte à 23 h 40 ne sert à rien si la seule réponse possible est d'ouvrir un ordinateur, retrouver la console de l'hébergeur, retrouver le bon déploiement et cliquer au bon endroit.
- pour remettre l'ancien en ligne
- 4 s
- reconstruction : le build existe déjà
- 0
- geste, depuis l'alerte ou l'app
- 1
- si vous l'avez décidé, par projet
- auto
chore: dépendances
feat: page contact
fix: typo sur les tarifs
feat: nouveau panier
Gardé, à corriger · Stripe.js ne charge plus
3 déploiements, tous vérifiés bons.
PostShip garde chaque mise en ligne sur Vercel avec son verdict. Le domaine sert le plus récent.
16:02 : 9f3c2e1 part en ligne.
Le domaine le sert dans la seconde, et la vérification part avec lui : 5 pages, une par une.
T+0 : /checkout ne passe pas.
Le déploiement est marqué en échec. L'alerte propose de revenir au dernier déploiement vérifié bon.
Revenir en arrière : 4 secondes.
Vercel remet le domaine sur 4b1d7a0. Le build existe déjà : rien n'est reconstruit.
Et revérifié aussitôt.
Les 5 pages repassent sur la version remise en ligne. Si elle échoue aussi, vous le savez tout de suite.
Rien n'est effacé.
9f3c2e1 reste sur le rail, avec son diagnostic, en attendant son correctif. En mode automatique, tout cela part sans vous.
3 déploiements, tous vérifiés bons.
PostShip garde chaque mise en ligne sur Vercel avec son verdict. Le domaine sert le plus récent.
16:02 : 9f3c2e1 part en ligne.
Le domaine le sert dans la seconde, et la vérification part avec lui : 5 pages, une par une.
T+0 : /checkout ne passe pas.
Le déploiement est marqué en échec. L'alerte propose de revenir au dernier déploiement vérifié bon.
Revenir en arrière : 4 secondes.
Vercel remet le domaine sur 4b1d7a0. Le build existe déjà : rien n'est reconstruit.
Et revérifié aussitôt.
Les 5 pages repassent sur la version remise en ligne. Si elle échoue aussi, vous le savez tout de suite.
Rien n'est effacé.
9f3c2e1 reste sur le rail, avec son diagnostic, en attendant son correctif. En mode automatique, tout cela part sans vous.
- 9f3c2e1feat: nouveau panierEn échec · /checkout
- 4b1d7a0fix: typo sur les tarifsEn ligne
- 7e3a9b2feat: page contactVérifié bon
- 2c91f04chore: dépendancesVérifié bon
Comment ça marche
PostShip connaît vos déploiements
Chaque déploiement Vercel est vu, vérifié et mémorisé avec son verdict.
Un geste depuis l'alerte
Le message — par email, dans Slack ou dans Discord — porte le bouton.
Ou tout seul, si vous le voulez
Par projet, vous pouvez décider que PostShip revient en arrière sans vous demander quand un déploiement de production casse une page qui passait juste avant.
Vérifié après, comme avant
Le retour arrière est un déploiement comme un autre : il est vérifié dans la foulée, et l'alerte de rétablissement part quand tout est repassé au vert.
Quand il part tout seul, et quand il ne part pas
Le retour automatique est la fonction la plus dangereuse du produit : elle agit sur votre production sans vous. Ses conditions sont donc étroites, et toutes cumulatives.
Il faut l'avoir armé sur ce projet
Éteint par défaut, et il le reste tant que vous ne l'allumez pas projet par projet. Un réglage global qui armerait tout d'un coup n'existe pas : ce n'est pas le genre de chose qu'on active par mégarde.
Seulement sur une page qui prend de l'argent
Une carte de partage cassée ne justifie pas de défaire une mise en ligne. Un tunnel de paiement mort, oui. La frontière est exactement celle de vos pages de paiement, celles que vous avez déclarées vous-même.
Seulement au premier passage
À la mise en ligne, pas 2 ni 8 minutes après. Passé ce délai, une panne peut venir d'ailleurs — d'un fournisseur, d'un certificat, du réseau — et défaire un déploiement innocent ferait plus de mal que de bien.
Jamais sur une preview
Une preview n'a pas de visiteurs à protéger, et la défaire ne répare rien. Le retour ne touche que les domaines de production.
Ce que le retour arrière ne fait pas
Remettre l'ancienne version en ligne répare la page, pas forcément la situation.
Il ne défait pas vos migrations
Le code revient, la base de données non. Si le déploiement a changé un schéma, le retour arrière remet en ligne un code qui parle à une base qu'il ne connaît plus. C'est la raison principale de laisser la fonction éteinte quand vos mises en ligne touchent au schéma.
Il ne reconstruit rien
L'ancien déploiement existe encore chez votre hébergeur : le retour ne fait que repointer les domaines de production dessus, en quelques secondes. S'il a été supprimé, il n'y a rien à remettre en ligne.
Il vise ce que PostShip a vu passer au vert
Pas simplement le déploiement précédent dans la liste de l'hébergeur. C'est la différence qui compte : le précédent peut être cassé lui aussi, et c'est au moment où l'on est pressé qu'on se trompe de ligne.
Vercel seulement, pour l'instant
C'est là que l'intégration dispose d'un jeton et d'une opération de retour qui ne reconstruit pas. Ailleurs, l'alerte contient le lien pour le faire à la main, et l'incident reste ouvert avec sa chronologie.