Quelles données versionner et comment
Les données versionnées sont stockées dans un dépôt Git séparé du dépôt de code (data repo distinct du code repo). Cette séparation permet de gérer les permissions différemment (les données peuvent contenir des informations sensibles), de ne pas polluer l’historique du code avec des fichiers binaires volumineux, et d’utiliser Git LFS pour les fichiers de grande taille (fichiers IGN Admin Express : 800 Mo).
Chaque build de production référence un commit précis du dépôt de données via un hash de commit versionné dans le fichier de configuration du build. Ce hash est mis à jour manuellement lors d’une mise à jour de données. Un build lancé sans spécification de hash utilise le dernier commit du dépôt de données, ce qui est acceptable pour les builds de développement mais interdit en production.
Test de reproductibilité mensuel
Le test de reproductibilité consiste à rejouer un build de production passé (build vieux de 30 jours) à partir du commit de code et du commit de données correspondants, et à comparer le hash SHA-256 de l’output avec le hash stocké lors du build original. Tout écart signifie qu’une source de non-déterminisme a été introduite dans le pipeline.
Les sources de non-déterminisme courantes sont : l’utilisation de la date courante dans un calcul (au lieu de la date du build passée en paramètre), une dépendance externe qui a changé (ex : une API externe appelée pendant la génération), ou un générateur pseudo-aléatoire non seedé. Chaque source identifiée est éliminée avant le prochain build de production.
Bénéfices opérationnels de la reproductibilité
La reproductibilité simplifie le débogage : pour investiguer un contenu publié plusieurs semaines plus tôt, on rejoue le build correspondant et on inspecte le résultat. Sans reproductibilité, le build actuel produit un résultat différent et l’investigation devient approximative.
La reproductibilité facilite également les audits : toute page publiée peut être générée à nouveau à partir des données et du code qui l’ont produite originellement. Cette traçabilité est utile quand un contenu est contesté (erreur factuelle, formulation inappropriée) : on peut identifier précisément quelle version des données et quel commit ont produit le contenu en question.
Questions fréquentes
Git LFS ajoute-t-il une complexité significative au workflow ?
Oui, une complexité modérée. Les développeurs doivent avoir Git LFS installé et configuré. Les clones du dépôt de données nécessitent l’option --filter=blob:none pour ne pas télécharger tous les fichiers LFS lors du clone initial. Cette configuration est documentée dans le README du dépôt de données.
Comment gérez-vous les données qui ne peuvent pas être versionnées (données commerciales confidentielles) ?
Ces données sont stockées en base de données chiffrée et référencées dans le build par un identifiant de snapshot plutôt qu’un fichier versionné. La reproductibilité est partielle dans ce cas : le build peut être rejoué à condition que le snapshot de données soit encore disponible, ce qui est garanti par la politique de rétention de la base de données (90 jours minimum).