Ausführbare Fences

COADF P-6: Eine Leitplanke, die in einem Dokument steht, ist ein Ratschlag; eine Leitplanke, die in der Pipeline läuft und ein Release stoppt, ist ein Fence. Fences fallen in vier Kategorien (Daten, Architektur, Text und Prozess), jeder mit einer Kennung, einer Regel und einer Durchsetzungsmethode, und ein Fence verdient seinen Platz erst durch einen Zahnbeweis. COADF veröffentlicht das Vokabular nicht, auf das sein eigener Veröffentlichungs-Fence anschlägt, denn eine Liste dessen, was beobachtet wird, ist eine Karte dessen, was geschützt wird.

Die Eigenschaft lautet nicht „es gibt eine Prüfung“. Sie lautet, dass der verbotene Zustand einen bestimmten Punkt nicht passieren kann und dass jemand zugesehen hat, wie er dort gestoppt wurde.

Jede andere Eigenschaft in diesem Companion lässt sich einmal korrekt umsetzen und mit der nächsten Änderung wieder verlieren. Ein Fence hält eine Eigenschaft über Änderungen hinweg wahr, die niemand mit Blick auf diese Eigenschaft geprüft hat. Das Schwierige ist selten, die Prüfung zu schreiben. Es ist, die Prüfung auf den Pfad zu setzen, den der verbotene Zustand nehmen muss, und zu belegen, dass sie dort anschlägt, auf dem echten Pfad, und nicht in einem Unit-Test der Prüffunktion.

Durchsetzungsflächen

Jede Fläche sieht etwas anderes, und jede hat eine typische Umgehung. Ein Fence gehört auf die Fläche, die den verbotenen Zustand sieht, und ist nur so stark wie die Umgehung dieser Fläche.

Drei Ketten, jede endet in einem gestoppten Übergang, sind in den Profilen umgesetzt:

• Ein Architekturverstoß lässt einen Architekturtest fehlschlagen, und der Merge findet nicht statt (Python und FastAPI).
• Eine Vertragsinkompatibilität lässt eine Vertragsprüfung fehlschlagen, und das Release findet nicht statt.
• Ein synthetischer verbotener Sentinel in der gebauten Website lässt den Veröffentlichungs-Fence fehlschlagen, und die Veröffentlichung findet nicht statt (Python und FastAPI, Cloud-native).

Continuous Integration ist eine Fläche unter neun, nicht die Definition eines Fence. GitHub Actions, GitLab CI und Jenkins können einen beherbergen; ebenso ein Typprüfer, eine Admission Policy oder der Build, der eine Website rendert.

Zahnbeweis

• Einen kontrollierten, synthetischen Defekt einbauen.
• Den echten Durchsetzungspfad durchlaufen, nicht einen Unit-Test der Prüffunktion.
• Verifizieren, dass er fehlschlägt, und zwar aus dem eingebauten Grund.
• Die exakte Fixture wiederherstellen und das durch einen Vergleich des Digests vorher und nachher belegen.
• Verifizieren, dass er wieder besteht.

Vor dem Einbauen committen. Wer durch Verwerfen der Änderungen wiederherstellt, stellt den letzten Commit wieder her, und der ist auf einem Arbeitszweig womöglich nicht der Ausgangspunkt; der Beweis zerstört dann genau die Arbeit, die er schützen sollte.

• Pre-Commit-Hooks. Schnelle Rückmeldung, und auf dem eigenen Rechner der Entwicklerin oder des Entwicklers umgehbar: ein Ratschlag, kein Fence.
• Laufzeitwächter. Sie stoppen einen verbotenen Zustand in der Produktion statt davor. Notwendig, wo der Zustand erst zur Laufzeit existiert.
• Manuelle Gates. Eine namentlich benannte Person führt ein schriftlich festgelegtes Verfahren aus. COADF weist eine solche Kontrolle ehrlich als manuell aus, nie als durchgesetzt.
• Policy-Engines für Infrastrukturregeln. Kubernetes ValidatingAdmissionPolicy im Prozess des API-Servers, oder Open Policy Agent mit Gatekeeper, wo der verbotene Zustand ein API-Objekt ist.

• Ein Text-Fence kann keinen Mechanismus sehen, der über Kontrollfluss, umbenannte Bezeichner, Datenfluss oder die Geometrie eines Diagramms ausgedrückt ist. Automatisierte Wächter sind notwendig und nicht hinreichend; die menschliche Prüfung bleibt.
• Ein Fence erkennt, wofür er geschrieben wurde, und sonst nichts.
• Bestandene Fences begründen, dass die Fences bestanden wurden. Einen regulatorischen Status begründen sie nicht.