Des versions qui protègent vos données avant de démarrer
· 4 min de lecture
Pendant que vous fabriquez un film, nous publions peut-être une nouvelle version de PageToVid sous vos pieds. Vos projets, storyboards et films vivent dans une même base de données, et une version qui en change la forme les touche tous à la fois. Nous voulions qu'une chose soit impossible : qu'une version fasse disparaître sans bruit quelque chose qui vous appartient.
Une nouvelle version, le même terrain sûr
Nous publions souvent, parfois plusieurs fois par jour. La plupart des versions ne changent que du code, mais certaines changent aussi la base : une nouvelle table pour une nouvelle fonction, un nouveau champ sur un film.
La promesse derrière chacune tient en une phrase. Rien de ce que vous avez créé ne doit dépendre du bon déroulement d'une version. Si une nouvelle version a un souci, l'ancienne doit continuer à vous servir, et vos données rester exactement telles quelles.
Le contrôle que chaque version passe à l'entrée
Quand une nouvelle version de PageToVid démarre, avant de servir la moindre page, elle met la base à jour avec Prisma, l'outil qui décrit nos tables. Nous lançons cette étape volontairement sans l'option qui accepte la perte de données.
Si un changement supprimait une colonne, convertissait un champ en risquant de perdre des valeurs, ou mettait autrement des lignes existantes en danger, l'étape refuse. La nouvelle version s'arrête avant de recevoir le moindre trafic, et Cloud Run, qui fait tourner nos serveurs, garde la version précédente en service comme si de rien n'était.
Tout changement de base suit donc une seule règle, n'ajouter que du neuf :
- de nouvelles tables
- de nouveaux champs facultatifs
- de nouveaux champs avec une valeur par défaut
Tout le reste attend à la porte jusqu'à ce qu'on lui donne une autre forme.
Une règle qui a l'air vide, mais ne l'est pas
Cette version apportait des liens courts et lisibles que chacun peut choisir, et deux personnes ne doivent jamais avoir le même. La façon naturelle de l'écrire : un nouveau champ sur la table des comptes existante, marqué unique.
Le champ était tout neuf et vide. Il avait l'air inoffensif. Mais une nouvelle règle d'unicité sur une table qui contient déjà des lignes compte comme une perte possible, car la base ne peut pas garantir d'avance qu'aucune ligne n'entre en conflit. Le contrôle d'entrée a donc fait exactement son travail : la version qui la portait a attendu, la précédente a continué à servir, et personne en train de faire un film n'a rien remarqué.
Nos tests ne pouvaient pas le voir. Ils construisent à chaque fois une base neuve et vide, et sur une table vide, un champ unique sur une nouvelle table ou sur une table existante, c'est pareil. La différence n'existe que là où vivent les vraies données, précisément là où se tient la garde.
Changer la forme des données, garder la garde
La réponse rapide aurait été d'activer l'option qui accepte la perte et de publier. Nous avons fait l'inverse. Nous avons changé la forme des données pour qu'elles passent le contrôle honnêtement.
Une règle créée en même temps qu'une nouvelle table est sûre, puisqu'une table neuve n'a aucune ligne en conflit. L'unicité de ces liens est donc passée dans une petite table à elle, avec le lien lui-même comme clé et une ligne par personne. Le compte en garde une simple copie pour l'affichage, sans règle.
Le changement est devenu purement additif. Nous l'avons vérifié contre la base en service avant de publier, et la fonction est sortie le jour même.
Une étape de plus avant tout changement de base
La leçon fait désormais partie de notre façon de publier. Avant qu'un changement de base parte, nous le comparons au schéma réellement en service, pas à la copie d'un développeur :
- prendre le schéma de la version actuellement en ligne, et le nouveau
- demander à Prisma les instructions exactes qu'il exécuterait entre les deux
- les lire : seulement de nouvelles tables, des champs facultatifs ou avec valeur par défaut, et des règles d'unicité sur de nouvelles tables
- faire une sauvegarde fraîche avant la mise en ligne
Ce qui ne doit jamais apparaître sur une table existante : une nouvelle règle d'unicité, un champ obligatoire sans valeur par défaut, un renommage ou une suppression. Chacun a une forme sûre connue, le plus souvent une nouvelle table.
Ce que cela change pour vos films
Vous ne voyez rien de tout cela, et c'est tout l'intérêt. Une version qui n'est pas prête ne démarre tout simplement pas, celle que vous utilisez continue, et vos projets et films restent exactement comme vous les avez laissés.
Une version qui attend à la porte, c'est un petit retard pour nous. Un champ disparu serait une perte pour vous. Nous avons choisi l'échange qui protège votre travail. D'autres histoires sur la construction de PageToVid vous attendent sur le blog.
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
