Dans l'IT, la donnée est clé. De bonnes décisions prises avec de mauvaises données sont source de gaspillage, voire catastrophiques. Et quand on multiplie les intervenants et les versions de ces données, il est important de mettre tout le monde d'accord sur la source de vérité à chaque instant.

1er d'une série dédiée aux concepts-clé de l'intégration continue, cet article vulgarise la notion centrale de source unique de vérité par une série de cas d'utilisations issus de contextes très différents, mais illustrant cette même problématique.

Cas n°1

Jean-Cadre participe à une avant-vente pour un projet. Comme toute l'équipe travaille sur les mêmes fichiers et se les échange, il se dit qu'il vaut mieux historiser tout changement pour ne rien perdre. Donc, JC ne modifie jamais le document d'origine, il préfère le copier et le renommer pour en faire une version spécifique. Ensuite, il joint cette copie à un mail à toute l'équipe. Cordialement.

Question

Jean-Cadre saura-t-il quelle est la dernière version entre

• 20220412_PROJET-1.1_PROPAL.1.06_valide-draftJEANCADRE (1).pptx
• Et
• 20220412_PROJET-0.9_PROPAL.2.0_V3.3 (2) 524XL98-copy.pptx ?

Idée reçue #1 : "il faut renommer pour versionner"

Au moins, il faut renommer l'ancien et l'archiver, ne conserver à l'emplacement prévu que la version qui fait foi à l'instant t pour toutes les parties prenantes : PROJET-1.0-PROPAL.pptx. La plupart des outils bureautique permettent désormais de travailler en même temps sur le document. Et de toute façon, ils historisent désormais automatiquement toutes ses modifications. Donc en vrai, plus besoin de renommer quoi que ce soit.

On partage 1 seule fois le lien (pas la copie) vers le document à toute l'équipe et on ne se trompe plus.

Cas n°2

Dave développe sur un projet, et pour ne pas polluer la branche de code principale, décide de créer une branche privée dédiée à sa fonctionnalité (feature branch), qu'il poussera dans la codebase une fois la fonctionnalité développée. 10j plus tard, Dave est ravi, il a mis le temps prévu et pousse sa branche sur un tronc qui bien sûr, a évolué depuis.

Question

Le 11e jour, sur quelle branche se situe la photo du projet ? Sera-t-il possible de livrer en prod ce jour-là ?

Idée reçue #2 : "tant que le code d'une fonctionnalité n'est pas terminé, on le garde sur sa branche"

Mais le risque de déphasage des branches aboutit à plusieurs sources de vérité. A l'instant t, quelle branche est la plus représentative du produit ? C'est pourquoi la branche principale doit être fréquemment mise à jour, en distinguant fonctionnalité terminée de "code stable". Il existe des mécanismes pour rationaliser le nombre de branches, tels que les branches par abstraction ou le feature flipping. Ce qui permet de continuer à livrer fréquemment des fonctionnalités toujours en cours de développement, mais avec un code stable. On gagne alors en temps et complexité de merge, en fréquence et légèreté des code reviews, et la recette devient ainsi continue, plutôt que tardive et couteuse.

Cas n°3

Ma* prépare un gâteau en suivant une recette écrite. A la fin, plutôt que d'en servir à ses convives, elle est inspirée et se dit qu'en rajoutant un glaçage au chocolat, cela sera bien mieux. Donc elle fait une mise à jour de son gâteau, puis le sert. C'est un gros succès. M est conquise. Elle fera toujours son gâteau de cette façon.

*les intervenants ont été anonymisés

Question

La prochaine fois, Ma pensera-t-elle à rajouter le glaçage ? Au moment de refaire son gâteau, sur quoi Ma ou sa compagne Mi devront elles se baser ? Sur la photo du dernier qui était très réussi mais pas décrit, ou sur la recette mais qui ne semble pas en phase ? Pourtant, les 2 sources de vérité semblent légitimes.

Idée reçue #3 : "ça va + vite de créer directement un dessert que d'en écrire la recette"

La 1ere fois oui. Mais dès la 2e fois, s'il faut tâtonner pour retrouver le même résultat…

Cas n°4

Laure a besoin d'ajouter une base de données sur l'environnement de développement de son projet mais en urgence alors plutôt que de préciser et rejouer le script de création de l'environnement, elle crée elle-même sa base de données et la paramètre toute seule. Ca fonctionne très bien, et vite. Mme Acle est contente.

Question

Au moment de recréer l'environnement à l'identique, sur quoi l'équipe de Laure doit-elle se baser : sur l'environnement de dev qui tourne bien, ou sur son script de création qui ne semble pas en phase ? A nouveau, 2 sources de vérité cohabitent dans le projet.

Idée reçue #4 : "ca va + vite de créer directement un environnement que de le scripter"

Ici la différence avec le gâteau, c'est que dans l'IT l'exécution du script (la recette de cuisine) est automatisée. Donc avec un script à jour, l'opération de recréation du projet devient répétable à coût 0, et idempotente (le même résultat à chaque exécution). Ce script devient la source de vérité pour toute l'équipe. Dès lors, on ne modifie plus l'environnement directement, mais on modifie son script et on l'exécute à nouveau. D'ailleurs si la base de données est corrompue un jour, il suffira de la détruire pour la réinstancier. Ce script étant du code, il aura le même cycle de vie que le code du projet, et se trouvera dans le même repository. Le code de la fonctionnalité et le script de création de cette base de données, feront ainsi partie du même build, qui devient alors le produit, indissociable de son environnement d'exécution. C'est d'ailleurs l'une des incohérences des acteurs de plateformisation tiers qui conservent la propriété de ce script, le rendant externe au code du projet et créant ainsi 2 cycles de vie.

Le build du produit doit être autoportant, et agnostique de son environnement cible. Là, on est #SSOT niveau expert, et on a déjà bien digressé sur un concept-clé du devops : l'infrastructure as code #IAC. C'est même le concept de forge chez NIJI.

On pourrait multiplier les exemples, le concept de SSOT est partout. Comme les patrons de conception, c'est un concept pérenne, qui a fait ses preuves. C'est aussi un gage de maturité et l'un (pas le seul) des prérequis pour espérer délivrer plus en continu.