Fences exécutables

COADF P-6 : un garde-fou qui vit dans un document est un conseil ; un garde-fou qui s'exécute dans la chaîne et bloque une livraison est un fence. Les fences se répartissent en quatre catégories (données, architecture, texte et processus), chacun avec un identifiant, une règle et une méthode d'application, et un fence ne mérite sa place que par une preuve de dents. COADF ne publie pas le vocabulaire sur lequel son propre fence de publication se déclenche, parce qu'une liste de ce qui est surveillé est une carte de ce qui est protégé.

La propriété n'est pas « il existe un contrôle ». C'est que l'état interdit ne peut pas dépasser un point donné, et que quelqu'un l'a vu y être arrêté.

Chaque autre propriété de ce Companion peut être mise en œuvre correctement une fois et perdue au changement suivant. Un fence est ce qui garde une propriété vraie à travers des changements que personne n'a relus en ayant cette propriété en tête. La difficulté est rarement d'écrire le contrôle. Elle est de placer le contrôle sur le chemin que l'état interdit doit emprunter, et de prouver qu'il se déclenche là, sur le vrai chemin, plutôt que dans un test unitaire de la fonction de contrôle.

Surfaces d'application

Chaque surface voit quelque chose de différent, et chacune a un contournement caractéristique. Un fence a sa place sur la surface qui voit l'état interdit, et il n'est pas plus fort que le contournement de cette surface.

Trois chaînes, chacune se terminant par une transition arrêtée, sont mises en œuvre dans les profils :

• Une violation d'architecture fait échouer un test d'architecture, et la fusion n'a pas lieu (Python et FastAPI).
• Une incompatibilité de contrat fait échouer un contrôle de contrat, et la livraison n'a pas lieu.
• Une sentinelle interdite synthétique dans le site construit fait échouer le fence de publication, et la publication n'a pas lieu (Python et FastAPI, Cloud-native).

L'intégration continue est une surface parmi neuf, pas la définition d'un fence. GitHub Actions, GitLab CI et Jenkins peuvent tous en héberger un ; un vérificateur de types, une politique d'admission ou le build qui rend un site le peuvent aussi.

Preuve de dents

• Introduire un défaut synthétique et contrôlé.
• Exercer le vrai chemin d'application, pas un test unitaire de la fonction de contrôle.
• Vérifier que cela échoue, et échoue pour la raison plantée.
• Restaurer la fixture exacte, et le prouver en comparant une empreinte avant et après.
• Vérifier que cela passe de nouveau.

Commiter avant de planter. Restaurer en abandonnant les modifications restaure le dernier commit, qui sur une branche de travail n'est pas forcément le point de départ, et la preuve détruit alors le travail qu'elle devait protéger.

• Des hooks pre-commit. Un retour rapide, et contournables sur la machine même du développeur : un conseil, pas un fence.
• Des gardes à l'exécution. Ils arrêtent un état interdit en production plutôt qu'avant. Nécessaires là où l'état n'existe qu'à l'exécution.
• Des barrières manuelles. Une personne nommée exécute une procédure écrite. COADF présente honnêtement un tel contrôle comme manuel, jamais comme appliqué.
• Des moteurs de politiques pour les règles d'infrastructure. ValidatingAdmissionPolicy de Kubernetes dans le processus, ou Open Policy Agent avec Gatekeeper, là où l'état interdit est un objet d'API.

• Un fence textuel ne peut pas voir un mécanisme exprimé par le flot de contrôle, des identifiants renommés, le flot de données ou la géométrie d'une figure. Les gardes automatisés sont nécessaires et non suffisants ; la revue humaine demeure.
• Un fence détecte ce qu'il a été écrit pour détecter, et rien d'autre.
• Des fences qui passent établissent que les fences ont passé. Ils n'établissent aucun statut réglementaire.