Définir un état reproductible - modèle YAML et loader (2/3)

Introduction

Un socle vide ne suffit pas.

Il faut pouvoir y appliquer un état.

Pas une saisie manuelle.
Pas une construction progressive.

Un état explicite.

Problème

Remplir NetBox à la main fonctionne.

Mais cet état :

• n’est pas versionné
• n’est pas reproductible
• dépend du contexte

Chaque test repart de zéro.

Changement d’approche

Décrire l’état en dehors de NetBox.

Sous une forme :

• lisible
• structurée
• versionnable

YAML

Le choix du YAML ne change pas le modèle.

Il change sa manipulation.

L’état devient :

• explicite
• visible
• rejouable

Loader

Le loader applique cet état dans NetBox.

Il ne fait pas que créer des objets.

Il garantit :

que l’état appliqué est cohérent

Idempotence

Un point central :

Appliquer deux fois le même modèle ne change rien.

Cela permet :

• de rejouer
• de corriger
• de stabiliser

Résultat

NetBox n’est plus rempli.

Il est reconstruit.

Conclusion

Le modèle n’est pas une optimisation.

C’est ce qui permet de garantir que chaque test repose sur un état maîtrisé.