Des mises en ligne qui se vérifient avant vous
· 4 min de lecture

Début juillet, nous publiions des améliorations de PageToVid plusieurs fois par jour, parfois coup sur coup. Chacune devait vous parvenir vite, et aucune ne devait jamais vous laisser sur une page qui ne fonctionne pas. Le 4 juillet, notre chaîne de mise en ligne a appris à vérifier son travail depuis l'extérieur, et à l'annuler d'elle-même.
Publier plusieurs fois par jour
Dès le tout premier commit, PageToVid avait une chaîne qui vérifie les types du code, construit un conteneur avec tout ce dont un film a besoin, du navigateur au moteur vidéo, et le déploie sur Google Cloud Run. C'est cette vitesse qui permet à une correction trouvée un lundi matin d'arriver dans votre prochain film l'après-midi même.
Début juillet, la chaîne en faisait davantage. Chaque version démarre propre, en détachant tout ce que la précédente avait rattaché, pour que rien d'ancien ne traîne dans la nouvelle. Et la tâche qui rend les films est déployée à partir de la même image que celle du site : le site et les rendus exécutent toujours le même code.
Terminé ne veut pas dire en ligne
Quand la dernière étape d'une mise en ligne réussissait, la tâche passait au vert. Mais le vert signifiait seulement que la plateforme avait accepté la nouvelle version. Il ne disait rien de trois choses qui comptaient vraiment :
- si les visiteurs atteignaient bien le nouveau code, et non une copie gardée par un cache devant le site
- si la nouvelle version pouvait parler à sa base de données
- quel commit, exactement, répondait à cet instant
Une version qui ne peut pas se voir elle-même n'est qu'une supposition. Nous voulions que chaque mise en ligne prouve, depuis l'extérieur, qu'elle servait vraiment et qu'elle était vraiment en bonne santé.
Chaque build signe de son nom
La première étape a été la traçabilité. Chaque version intègre désormais son commit, sa branche, son exécution de chaîne et son heure de construction dans le service en marche. On les retrouve à deux endroits :
- un point de santé qui indique l'état, le commit, une vérification en direct de la base de données et la durée de fonctionnement, sans jamais être mis en cache
- un en-tête de version sur chaque réponse du site
Chaque version en service porte aussi le nom de son exécution et l'étiquette de son commit : chaque version correspond à un seul commit. Quand un film ou une page semble anormal, la première question, quel code est-ce, a maintenant une réponse en une seconde.
Une vérification vue de l'extérieur
Après le déploiement, la chaîne interroge maintenant ce point de santé par la périphérie du réseau public, le chemin même que prend un visiteur, en contournant le cache. Elle redemande jusqu'à ce que la réponse indique le commit exact qui vient d'être déployé et une base de données qui répond. Si cela n'arrive pas à temps, la mise en ligne échoue.
Passer par la périphérie plutôt que par l'adresse propre du service compte. On teste ce que vous atteignez vraiment, y compris tout ce qui se trouve devant l'application. Une mise en ligne n'est terminée que lorsque le monde extérieur la voit.
La vérification de la base compte pour la même raison. Une version qui démarre mais n'atteint pas ses données répondrait à un simple ping et échouerait pourtant à chaque vraie requête. Le point de santé interroge lui-même la base et rapporte le résultat : la vérification s'en aperçoit bien avant vous.
Revenir en arrière tout seul
Quand la vérification échoue, la chaîne renvoie immédiatement le trafic vers la version qui servait juste avant. Personne n'a besoin de le remarquer, de se réveiller ou de taper une commande : une version qui ne peut pas faire ses preuves ne reste tout simplement pas. Chaque exécution se termine par un court résumé de ce qui a été déployé, de ce que la vérification a vu et de la suite.
Nous avons aussi conservé le cache de construction d'une exécution à l'autre, ce qui rend chaque nouveau build bien plus rapide. C'est plus important qu'il n'y paraît. Plus une correction se construit vite, moins il coûte de revenir en arrière et de réessayer, et plus tôt l'amélioration atteint vos films.
Ce que cela change quand vous faites un film
Vous ne voyez rien de tout cela, et c'est le but. Vous collez un lien, et la page qui répond est la version qui vient de passer sa vérification, reliée à ses données, avec le même code que le moteur qui filmera votre site. Quand une nouveauté n'est pas prête, la version précédente continue de vous servir, sans interruption.
Cela nous permet aussi d'améliorer PageToVid plusieurs fois par jour sans vous imposer de fenêtre de maintenance. Si vous construisez sur PageToVid, la page développeurs présente l'API qui tourne sur cette chaîne, ou vous pouvez simplement créer un film.
Voyez-le sur votre propre site
Collez une page et obtenez la vidéo commentée dont parle ce blog. La première est offerte.
À lire ensuite


