Chaque version qui passe ses contrôles est mise en ligne

Notre chaîne de publication suit un schéma classique. Elle construit la nouvelle version, la démarre à côté de l'actuelle, vérifie qu'elle répond en bonne santé, et seulement ensuite la laisse servir. Si la nouvelle version échoue à ce contrôle, un filet de sécurité renvoie les visiteurs vers la précédente.

Ce sont deux promesses, pas une. Une version saine doit être mise en ligne, et une version malade ne doit pas l'être. Cette semaine, en livrant la nouvelle planification de vidéos par site, nous avons examiné les deux de près : la seconde était solide, la première reposait sur une supposition.

Nous voulions qu'il soit impossible qu'une version saine reste en coulisses. Nous avons donc passé en revue chaque étape qui décide où va le trafic.

Un filet de sécurité ne vaut que par son déclencheur. Le nôtre partait dès qu'une étape antérieure avait échoué, y compris des étapes qui tournent avant qu'une nouvelle version ne serve qui que ce soit, comme la construction elle-même. Dans ces cas, il n'y a rien à annuler, et intervenir fait plus de mal que de bien.

Nous l'avons resserré sur le seul moment pour lequel il existe : une nouvelle version est passée en ligne puis a échoué à son contrôle de santé. Si un problème antérieur a empêché ce contrôle de tourner, le filet reste désormais à l'écart.

Tester le nouveau déclencheur avec un contrôle volontairement en échec nous a appris deux subtilités, et nous avons corrigé les deux :

1. 1L'étape qui mémorise la version en service choisit maintenant celle qui porte vraiment le trafic, et non simplement la première de la liste.
2. 2Dans GitHub Actions, une condition qui ne nomme aucun statut est discrètement limitée au cas où tout a réussi. Une condition de retour arrière doit écrire failure() explicitement, sinon elle ne peut jamais se déclencher au moment où elle compte.

L'enseignement le plus profond portait sur la façon dont notre plateforme d'hébergement, Cloud Run, achemine le trafic. Par défaut, elle sert la version saine la plus récente. Mais quand on dirige tout le trafic vers une version nommée, comme le fait un retour arrière, la plateforme retient ce choix et continue de servir cette version, même quand de plus récentes arrivent.

C'est un comportement raisonnable, et il signifiait que notre chaîne ne pouvait pas simplement supposer que la version la plus récente était celle en service.

Nous avons donc ajouté l'étape qui transforme la supposition en garantie. À la fin de chaque déploiement, la chaîne demande à la plateforme de servir la dernière version. Quoi qu'il se soit passé avant, un retour arrière, un test, un réglage manuel, une publication réussie se termine avec la version que nous venons de livrer devant vous. L'acheminement du trafic est passé d'un espoir à une affirmation de chaque déploiement.

La même semaine, nous avons resserré un autre détail. Nos versions sont construites à partir d'une copie propre du code, pas depuis la machine d'un développeur : un changement doit donc être complet dans le commit lui-même. Un import de type resté sur la machine pendant que sa fonctionnalité partait dans le commit nous a montré combien c'est facile à manquer.

Le correctif tenait en une ligne d'import, et l'habitude qu'il a renforcée vaut davantage. Avant qu'un commit parte, nous le vérifions dans une copie propre, exactement comme la construction le verra, et non dans un dossier de travail rempli d'autres modifications.

Ensemble, ces changements rendent les publications plus sereines pour tout le monde :

• une construction qui n'est pas prête ne vous atteint jamais,
• une version saine vous atteint toujours,
• et une version qui trébuche après sa mise en ligne est remplacée par la précédente en quelques instants.

Vous ne verrez rien de tout cela, et c'est tout l'intérêt. Quand nous écrivons sur ce blog qu'une chose a été livrée aujourd'hui, elle est en ligne aujourd'hui, pour chaque film que vous faites. La planification par site qui a lancé ce travail, des idées et des listes de plans pour chaque site ajouté, est arrivée chez tout le monde le jour même.

Pour qui gère sa propre chaîne de publication, la leçon est courte. Un mécanisme de sécurité est du code, lui aussi, et mérite les mêmes tests que ce qu'il protège, dans la situation exacte pour laquelle il a été écrit. Et une chaîne au vert prouve que les étapes ont tourné : faites qu'une de ces étapes prouve que la nouvelle version est bien celle en service.

Suivez chaque nouveauté au moment où elle sort sur le blog.