Sauvegardé chaque jour, chaque crédit justifié

Votre compte, vos projets, vos storyboards et vos crédits vivent dans une seule base de données. Chaque mise en production peut en modifier la structure, car nos conteneurs appliquent le dernier schéma au démarrage. Cela garde les mises en production simples, et cela signifie que chaque mise en production modifie aussi la base. Nous voulions qu'il soit impossible de perdre une journée de travail.

La base dispose donc désormais :

• de sauvegardes automatiques quotidiennes, conservées deux semaines ;
• d'une restauration à un instant précis, à la minute près dans cette fenêtre ;
• d'une protection contre la suppression, pour qu'elle ne puisse pas être effacée par erreur.

Nous avons fait une sauvegarde manuelle avant d'activer tout cela, puis vérifié que la première sauvegarde automatique s'était bien terminée. Et nous avons gardé une habitude de ce jour-là : avant toute mise en production qui modifie le schéma, une sauvegarde fraîche, mentionnée dans les notes de version.

Chaque mouvement de crédits a deux moitiés. Le solde change en une étape, puis une ligne de registre dit pourquoi : quel film, quel motif, combien. Le solde, c'est ce que vous dépensez ; le registre, c'est ce qui permet de le comprendre, à vous comme à nous.

La ligne de registre est maintenant écrite avec le même soin que le solde. Si elle ne peut pas être écrite du premier coup, elle est retentée après une courte pause. Si cela échoue encore, nous recevons une erreur avec tout ce qu'il faut pour l'écrire à la main, si bien qu'aucun mouvement ne reste jamais sans motif.

Au passage, nous avons ajouté un index sur le film auquel chaque ligne se rapporte. L'outil de statut consulte ces lignes à chaque vérification : demander où en est un rendu est donc aussi devenu plus rapide.

Un registre ne vaut que par le contrôle qui le lit. Nous avons donc ajouté un rapprochement : pour chaque compte, le solde est-il égal aux crédits d'ouverture plus la somme de tous les mouvements enregistrés ? Tout compte où ce n'est pas le cas apparaîtrait aussitôt, le plus gros écart en premier.

Le contrôle tient compte des crédits d'ouverture de chaque nouveau compte, et un test maintient ce chiffre égal à la valeur par défaut de la base, pour que les deux ne divergent jamais en silence. À sa première exécution complète, la lecture était de zéro. Chaque solde s'expliquait par ses mouvements, et un contrôle qui affiche zéro pour la bonne raison est celui auquel on peut se fier.

Quand quelque chose échoue dans un rendu, nous voulons le savoir avant que vous ayez à nous le dire. Nous avons choisi de ne pas ajouter de prestataire. Une petite fonction écrit désormais chaque échec sous forme de ligne de journal structurée, au format que comprend le service de rapport d'erreurs de Google Cloud : gravité, pile d'appels, service et version, plus le film ou le compte concerné.

La plateforme regroupe les répétitions, les compte et peut nous alerter. Aucune bibliothèque en plus, aucune clé en plus, rien de plus à entretenir. Elle est branchée sur le gestionnaire d'échecs général du pipeline et sur le registre, les deux endroits où une panne compte le plus pour vous.

Le dernier correctif concernait nos propres contrôles. Le test du registre de crédits avait besoin d'un utilisateur existant, et notre environnement de test automatique démarre toujours sur une base vide. Il crée maintenant son propre utilisateur temporaire, lui applique toutes les règles sur les crédits, puis le supprime. Les règles qui protègent votre solde s'exécutent désormais à chaque modification.

Rien de tout cela ne change ce que vous voyez à l'écran, et c'est tout l'intérêt. Ce sont les filets sous le trapèze :

• vérifier que les sauvegardes existent, et que la première a fonctionné ;
• rapprocher l'argent depuis deux côtés indépendants ;
• s'assurer que chaque test de sécurité s'exécute vraiment.

Si vous développez avec notre API, la documentation développeurs montre comment crédits et remboursements apparaissent dans le statut de chaque film.