Un dossier par scénario

Jusqu’à cette version, un dossier de travail Nexmesh ressemblait à ça :

Nexmesh/
  apk/
  data/            les CSV de tout le monde
  output/          les relevés de tout le monde
  logs/            les journaux de tout le monde
  scenarios/
    preparation-tc22/
      scenario.yaml

Quatre dossiers à la racine, dont trois partagés par tous les scénarios. C’est le rangement le plus simple à écrire, et il tient très bien tant qu’on n’a qu’une préparation. À la cinquième, il commence à coûter.

Ce qui coûtait

Retrouver le bon fichier. Le sélecteur de CSV s’ouvrait sur un dossier qui mélangeait les lots de licences de trois préparations différentes. Rien n’empêchait de lancer une préparation sur un fichier qui n’avait pas les bonnes colonnes, et on ne s’en apercevait qu’au premier appareil, une fois tout branché.

Rattacher un journal. Un journal avait une fiche à côté de lui, et c’est elle qui disait de quel scénario il venait. Si la fiche manquait ou était abîmée, après un arrêt brutal ou une copie incomplète, le journal n’était plus rattaché à rien. Il restait lisible, mais l’historique du scénario ne le voyait plus.

Copier une préparation. On copiait le dossier du scénario sur l’autre poste, et on laissait derrière soi tout ce qu’il avait écrit.

Ce qu’on a fait

Les trois dossiers descendent d’un cran :

Nexmesh/
  apk/                      commun : deux scénarios installent la même appli
  scenarios/
    preparation-tc22/
      scenario.yaml
      .metadata
      data/                 ses CSV d'entrée
      output/               ses relevés
      logs/                 ses journaux, et leurs fiches

Le dossier de travail ne garde plus que ce qui est vraiment commun, et il ne reste qu’une chose dans ce cas : les APK. Deux préparations installent souvent la même application, et la dupliquer par scénario ferait descendre deux fois cent mégaoctets. Un lot de licences, lui, ne sert qu’à la préparation qui le consomme. Et un relevé ne se lit qu’en regard du scénario qui l’a produit.

Quatre conséquences

Les dossiers se créent à la demande. Un scénario qu’on écrit sans jamais le lancer n’a aucune raison d’avoir un output/ vide.

Le dossier dit à quel scénario appartient un journal. Avant, seule la fiche le disait. Maintenant un journal sans fiche reste rattaché : ses appareils se retrouvent à la lecture, et son scénario est celui de son dossier.

Rien de tout ça ne monte vers le service. C’est la règle la plus importante des quatre. Les journaux ont déjà leur propre canal et arriveraient en double. Les relevés contiennent les données des appareils et dépasseraient la limite de cinq mégaoctets en une journée d’atelier. Quant au CSV au fil de l’eau, il est réécrit à chaque lancement : en cinq exécutions, il aurait vidé l’historique du scénario de ses cinq révisions.

Rien n’est déplacé tout seul. Si votre dossier de travail date d’avant, il garde ses data/, output/ et logs/ communs. L’historique continue de les lire, parce que les perdre de vue serait pire que de les laisser où ils sont. Et le sélecteur d’import s’ouvre sur l’ancien data/ tant que le scénario n’a pas le sien, ce qui réduit la reprise à un clic. Une conversion existe, mais elle se demande : une application qui réorganise vos fichiers au premier lancement, ça n’inspire pas confiance.

Le détail qui fait tenir le reste

L’identifiant d’un scénario, c’est le nom de son dossier. Un seul segment, pas de niveau intermédiaire. Ça remplace la validation de chemin qu’on traînait avant, et ça permet surtout de dire d’un journal : il est là, donc il est à celui-ci.

Le reste vit dans une fiche .metadata à côté du déroulé, c’est-à-dire un identifiant stable que le renommage ne change pas, et les dates. Le nom lisible et la description restent dans le scénario, parce que c’est le schéma qui les valide et qu’ils doivent voyager avec le fichier.