Als mir klar wurde, dass ich Preflight falsch anging
Lange dachte ich, Preflight bedeute „prüfen, ob der Server erreichbar und Ansible installiert ist". Technisch funktioniert das, aber praktisch reicht es nicht aus. Ein Run, den man gegen den falschen Server oder mit einer ungültigen Variable auslöst, besteht diese Art von Preflight und richtet dann genau den Schaden an, den man vermeiden wollte.
Der Wendepunkt war ein konkreter Vorfall: ein Staging-Run mit DB_HOST versehentlich auf einen Produktionswert gesetzt, der aus einem anderen Workspace kopiert worden war. Preflight meldete nichts, weil der Server erreichbar war. Der Run lief durch. Die Produktionsdatenbank erhielt inkonsistente Daten.
Was echtes Preflight abdecken muss
Nach diesem Vorfall schrieb ich neu, was Preflight in LaraDep bedeutet. Technische Erreichbarkeit reicht nicht — man muss den Kontext des Runs überprüfen. Vier Dinge haben mir seitdem mehr Stress erspart, als ich erwartet hatte:
- Korrektheit des Targets: Ist das wirklich der Server oder die Gruppe, die ich ändern will? Kein versehentlicher Staging/Produktions-Tausch.
- Vollständigkeit der Eingaben: Sind alle Pflichtfelder mit sinnvollen Werten befüllt?
- Konfigurationskonsistenz: Befinden sich die Abhängigkeiten, auf die das Template setzt, im erwarteten Zustand?
- Berechtigungsprüfung: Hat der angemeldete Benutzer das Recht, diese Änderung in diesem Workspace auszuführen?
Wie das in der Praxis aussieht
Preflight in LaraDep ist ein Gate, kein Statuslicht. Wenn eine Bedingung nicht stimmt, startet der Run nicht, und man bekommt eine konkrete Beschreibung, was fehlt. Das ist keine höfliche Warnung — das ist ein hartes Stopp. Anfangs hat mich das ein wenig geärgert. Dann erinnerte ich mich an diesen Vorfall und begann es zu schätzen.
Für Teams, in denen mehrere Personen Änderungen auslösen, ist das besonders wichtig. Ein erfahrener Operator führt mental selbst ein Preflight durch. Ein Junior oder ein neuer Kollege tut das nicht — und das Gate ist das, was sie vor ehrlichen Fehlern schützt.
Was Preflight nicht lösen wird
Preflight fängt keine logischen Fehler im Playbook selbst ab. Wenn das Template das Falsche korrekt tut, sagt Preflight einem das nicht. Deshalb müssen gute Template Composition und Workflow-Disziplin neben Preflight existieren, nicht statt ihm. Jede Schicht löst ein anderes Problem.
Nächster Schritt: Vollständiger Kontext steht in der Dokumentation und im Vergleich.