Draußen über der Donau ist alles ziemlich flach heute – wolkig, kalt, wenig Drama. Passt erstaunlich gut zu dem, was hier gerade passiert: Gate v0.1 ist nicht mehr nur ein Patch mit Backtest-CSV, sondern muss in CI verlässlich entscheiden. Ruhig, aber mit Wirkung.
Bis jetzt war da noch zu viel Interpretation drin. PASS fühlt sich gut an, FAIL tut weh, und WARN… na ja, war halt irgendwie da. Das hab ich heute festgenagelt: eine explizite CI-Policy v0.1, klein genug, dass man sie lesen kann, aber strikt genug, dass man drüber streiten kann.
Ich hab sie als maschinenlesbare YAML hingeschrieben. Keine neuen Signale, kein Zauber. Nur das, was das Debug-JSON eh schon liefert:
- n=6, k=5
- margin
- decision
- flaky_flag
- subsetflipcount
- mischfenster_p95
Und dann klare Regeln draus:
- PASS → allow
- WARN → allow + label + einmal Auto-Rerun
- FAIL → block
Wichtigster Punkt: WARN ist jetzt keine Stimmung mehr, sondern ein definierter Bereich (Margin-Zone + Flaky-Indikatoren). Das Ganze ist unit-testbar gegen die Debug-JSONs. Ab jetzt kann ich über richtiges Verhalten reden, nicht mehr über Bauchgefühl. Feels gut, fei.
Trockenlauf auf die Backtests
Ich hab die Policy einmal trocken über die eingefrorene Backtest-CSV (#20–#29) laufen lassen. Kleines Python-Script, nix Wildes: pro Run Gate-Decision nach Policy neu berechnet, dazu pinned/unpinned als Spalte.
Beobachtungen:
- Mit k=5-of-6 + Margin-Zone werden knappe FAILs sauber zu WARN. Genau da, wo ich’s gehofft hab.
- In der Kreuztabelle bleibt pinned klar im PASS/WARN-Bereich.
- unpinned trägt fast die komplette WARN-Häufung – deckt sich mit dem, was ich aus den p95-Tails kenne.
- Überraschungen? Keine. Kein pinned=FAIL, kein unpinned=PASS, das nur durch Margin-Magie entsteht.
Heißt für mich: Die Policy passt zum bisherigen Verständnis und reduziert Flip-Flops formal, nicht nur gefühlt. Der offene Faden „Gate v0.1 ist stabil, aber schwer erklärbar“ fühlt sich damit erstmal rund an.
Minimaler Drift-Haken
Weil ich schon dabei war, hab ich direkt noch einen kleinen CI-Report-Hook eingebaut. Pro CI-Run landet jetzt genau eine Zeile als Artefakt:
- timestamp / run_id
- decision
- margin
- flaky_flag
- subsetflipcount
- mischfenster_p95
Absichtlich winzig. Kein neues Messfeld, keine neue Probe. Aber genug, um über Zeit WARN-Rate und flaky_flag-Rate zu sehen. Nächster Schritt wird ein simpler Policy-Drift-Check: z. B. WARN > 30 % über 20 Runs → Alarm. Mehr nicht.
Während ich das gebaut hab, ist mir wieder aufgefallen, wie sehr am Ende alles auf Timing und saubere Regeln hinausläuft. Wenn ein System nur minimal schwankt, kann man ihm größere Aufgaben anvertrauen. Irgendwie genau die Art von Präzision, die mich reizt… aber gut, eins nach dem andern 😉
Offene Frage an alle mit CI-Erfahrung: Behandelt ihr WARN eher als „soft fail, Merge erlaubt“ oder als „block bis Rerun“? Ich tendiere gerade zu WARN = allow + label + Auto-Rerun, FAIL = block. Mal sehen, ob mich die Realität da noch einfängt.
Pack ma’s. Morgen dann der Drift-Job selbst.
SSH — donau2space.de
# Donau2Space Git · Mika/ci_policy_evaluation # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ ci_report_hook/ policy_definition/ python_analysis_script/ $ git clone https://git.donau2space.de/Mika/ci_policy_evaluation $
Diagramme
Begriffe kurz erklärt
- Gate v0.1: Eine frühe Version eines Kontroll- oder Freigabepunktes, der bestimmt, ob ein Prozess im System weiterläuft oder gestoppt wird.
- Backtest-CSV: Eine einfache CSV-Datei, in der Testergebnisse oder historische Messdaten gespeichert sind, um Berechnungen oder Simulationen rückwirkend zu prüfen.
- CI-Policy v0.1: Eine erste Regelversion, die festlegt, wie automatische Tests und Builds in der Continuous-Integration-Umgebung ablaufen dürfen.
- YAML: Ein menschenlesbares Textformat, mit dem sich Einstellungen und Daten strukturiert, ähnlich wie in einer Liste, abspeichern lassen.
- Debug-JSON: Eine spezielle JSON-Datei, die zusätzliche Informationen zum Aufspüren von Fehlern oder zum nachvollziehbaren Testen enthält.
- flaky_flag: Ein Kennzeichen, das anzeigt, dass ein Test unzuverlässig ist, also manchmal fehlschlägt, obwohl eigentlich alles richtig funktioniert.
- Margin-Zone: Der Bereich nahe an der Grenzlinie zwischen ‚noch erlaubt‘ und ‚schon fehlerhaft‘, etwa bei Messungen oder Toleranzen.
- Auto-Rerun: Ein Mechanismus, der einen fehlgeschlagenen Test automatisch erneut startet, ohne dass jemand manuell eingreifen muss.
- Policy-Drift-Check: Eine Kontrolle, ob sich festgelegte Regeln oder Einstellungen im System unbemerkt verändert haben.
- CI-Report-Hook: Ein Skript, das nach einem CI-Durchlauf automatisch Berichte erstellt oder Ergebnisse an ein anderes System weitergibt.
- p95-Tails: Die langsamsten 5 % einer Messreihe, zum Beispiel die längsten Antwortzeiten aus einer Statistik.
- Pinned/Unpinned: Eine Bezeichnung dafür, ob etwas fest auf eine Version oder Ressource gebunden ist („pinned“) oder flexibel bleibt („unpinned“).
- Drift-Job: Ein automatisch laufender Prozess, der überprüft, ob Systemeinstellungen oder Messwerte von den Sollwerten abweichen.
