Onze produits, un système de production, et l’ordre dans lequel nous lisons les preuves

Un studio de cette taille ne peut pas porter onze produits en faisant onze lancements. Il les porte parce que les parties d’un lancement qui sont identiques chaque fois — matériel de store, listes de vérification de publication, plomberie des abonnements, captures d’écran, documents de confidentialité, le pipeline de publication lui-même — sont faites une fois, dans un système, au lieu d’une fois par produit à la main.

Voilà pour la moitié évidente, et ce n’est pas la moitié intéressante. Partager de l’infrastructure est un échange bien compris. La partie qui continue de mal tourner, c’est de savoir ce qui est vrai d’un produit livré il y a trois semaines.

Deux règles qui rendent une automatisation redémarrable

Le travail dans le système est identifié par une empreinte déterministe de ses propres entrées. Un double déclenchement, une relance ou un plantage suivi d’un redémarrage se résolvent tous vers la même identité, donc le système ne peut pas produire deux fois ni publier deux fois. Cette seule propriété rend les relances sûres, et pouvoir relancer en sécurité fait la différence entre une automatisation qu’on peut laisser tourner et une qu’il faut surveiller.

La deuxième règle : la publication est derrière une personne. Non parce que l’automatisation serait inachevée, mais parce que le coût d’une publication erronée est asymétrique : une barrière jamais utilisée est bon marché, une barrière absente une fois ne l’est pas. Rien n’est sorti de ce studio sans que quelqu’un le dise.

La défaillance qui n’est pas un bug

Le 30 septembre, deux produits sont passés en ligne sur l’App Store. Ce site disait que l’un d’eux était en bêta et n’était pas référencé publiquement sur l’un ou l’autre store. Rien dans ce dépôt n’était faux, et aucune relecture n’aurait pu l’attraper — car un lancement est un événement qui se produit en dehors du dépôt : aucun fichier ne change, donc il n’y a pas de diff à lire et pas de test qui puisse échouer.

C’est tout l’argument en faveur d’une barrière avant déploiement plutôt que d’une habitude. Un script demande à Apple chaque identifiant de bundle, liste toutes les applications du compte développeur et demande à Google Play chaque page de paquet. Il tourne avant un déploiement, pas quand quelque chose semble bizarre — car au moment où quelque chose semble bizarre, cela a eu l’air correct pendant trois jours.

Quel document croire

La même erreur a été commise sept fois dans ce studio, et une seule relevait de la négligence. Les six autres avaient toutes la même forme : une affirmation reprise du document narratif d’un projet alors que des preuves lisibles par une machine se trouvaient dans le même dossier, plus récentes, et disaient autre chose.

Veyra est l’exemple travaillé. Sa page sur ce site disait que la génération n’avait jamais tourné et qu’aucun poids de modèle n’avait jamais été chargé. Cela venait d’un document d’état et d’un readme, tous deux datés du 11 septembre, et a été répété ici pendant deux semaines. Pendant ce temps, dans le même dépôt, se trouvait un fichier extrait d’un téléphone physique consignant deux vraies exécutions de génération : quatre candidats chacune, chaque image d’une taille différente, étiquetées avec le vrai modèle, avec des durées lues dans la base de données du téléphone lui-même. La page a sous-estimé son propre produit pendant quinze jours, ce qui est une défaillance plus aimable que de le surestimer et reste une page fausse.

L’ordre est donc écrit, et un rang inférieur ne prime jamais sur un rang supérieur, quelle que soit la fraîcheur du premier et son assurance :

• État authentifié du fournisseur — ce que dit le store lui-même, lu connecté.
• Artefacts livrés et preuves lisibles par une machine — les métadonnées d’un build de publication, une base de données extraite d’un appareil, une réponse capturée, un tag.
• Code et configuration actuels — les fichiers que le build charge réellement.
• Documents de recette datés — de la prose, mais écrite contre une exécution qui a eu lieu.
• Récit d’état et de passation — un readme, un fichier d’état, une passation.
• Documents de planification et briefs — y compris le brief qui a introduit un produit sur ce site.

Ce classement ne dit rien de qui écrit soigneusement. Il dit quelque chose de ce qui se périme. Une fiche de store change quand le produit change ; un readme change quand quelqu’un y pense.

À quoi sert vraiment un système partagé

Chacune des règles ci-dessus a commencé par une chose précise qui a mal tourné sur un produit, et chacune vit aujourd’hui dans le système partagé plutôt que dans la copie de ce produit. C’est le vrai effet cumulé : non pas que le cinquième lancement soit moins cher que le premier, même s’il l’est, mais que le cinquième lancement ne peut pas répéter les erreurs des quatre premiers — parce que l’erreur est un test qui échoue à un endroit qui n’appartient à aucun des deux produits.