Ein Deployment kann technisch vollständig erfolgreich durchlaufen und trotzdem eine Software hinterlassen, die nicht richtig funktioniert. Genau deshalb möchte ich mein zukünftiges automatisiertes Deployment mit Codex nicht danach bewerten, ob ein Skript ohne Fehlermeldung beendet wurde, sondern danach, ob die Anwendung anschließend tatsächlich den erwarteten Zustand erreicht hat.
Das klingt zunächst selbstverständlich, wird in automatisierten Prozessen aber schnell übersehen. Wenn ein Build erfolgreich war, das Paket übertragen wurde, die Dienste neu gestartet sind und kein Befehl einen Fehler zurückgegeben hat, entsteht leicht der Eindruck, die Arbeit sei abgeschlossen.
Für mich beginnt an dieser Stelle erst die nächste Prüfung.
In meiner geplanten Prozesskette von der Idee bis zur produktiven Software ist das Deployment deshalb bewusst nicht der letzte Schritt. Danach muss automatisch überprüft werden, ob die neue Version tatsächlich funktioniert und ob der produktive Zustand dem entspricht, was vorher spezifiziert wurde.
Was bedeutet „Deployment erfolgreich“ eigentlich?
Technisch kann ein Deployment sehr unterschiedliche Dinge umfassen. Dateien werden kopiert, Container ersetzt, Dienste neu gestartet, Datenbankmigrationen ausgeführt oder Konfigurationen verändert. Wenn all diese Schritte ohne technische Fehlermeldung abgeschlossen werden, war der Deployment-Prozess zunächst erfolgreich.
Das sagt aber noch wenig darüber aus, wie sich das Gesamtsystem danach verhält.
Ein Dienst kann erfolgreich neu gestartet werden und wenige Sekunden später wieder ausfallen. Eine Anwendung kann erreichbar sein, aber bei der ersten Datenbankabfrage scheitern. Eine Migration kann formal abgeschlossen werden, obwohl ein Teil der vorhandenen Daten anschließend nicht mehr zu den Erwartungen der Anwendung passt.
Selbst eine Webseite, die im Browser wieder erscheint, beweist nur sehr wenig.
Deshalb möchte ich zwischen zwei Dingen unterscheiden:
Wurde das Deployment technisch ausgeführt?
und:
Ist der gewünschte produktive Zustand erreicht?
Erst die zweite Frage entscheidet für mich darüber, ob die Aufgabe wirklich abgeschlossen ist.
Automatisierung darf nicht beim Kopieren der Dateien enden
Wenn Codex später nach meiner Freigabe ein Deployment übernimmt, soll es nicht lediglich eine vorbereitete Befehlsfolge ausführen.
Der gesamte Vorgang muss als zusammenhängender Prozess verstanden werden.
Vorher sollte geprüft werden, welche Version ausgerollt wird, ob notwendige Voraussetzungen erfüllt sind, ob Datenbankänderungen notwendig werden und welche Systeme von der Änderung betroffen sind. Anschließend folgt die eigentliche Auslieferung, danach wiederum eine gezielte Prüfung des Ergebnisses.
Diese letzte Phase ist für mich besonders wichtig, weil sich dort zeigt, ob die Automatisierung tatsächlich funktioniert oder nur technische Befehle aneinanderreiht.
Wenn ein Mensch jedes Mal nach dem automatischen Deployment manuell alle wichtigen Funktionen kontrollieren muss, ist zwar die Auslieferung automatisiert, aber der Gesamtprozess nur teilweise.
Ein Healthcheck ist hilfreich, aber nicht ausreichend
Viele Anwendungen besitzen Healthchecks, und das ist eine sehr sinnvolle Grundlage.
Ein Dienst kann damit beispielsweise melden, ob er läuft, ob eine Datenbank erreichbar ist oder ob eine wichtige abhängige Komponente antwortet.
Das ist für eine automatisierte Prüfung wertvoll.
Trotzdem würde ich mich nicht ausschließlich darauf verlassen.
Ein Healthcheck prüft schließlich nur genau die Dinge, für die er gebaut wurde. Eine Anwendung kann technisch gesund erscheinen und trotzdem fachlich ein Problem besitzen.
Vielleicht lässt sich die Startseite aufrufen, aber ein wichtiger Prozess schlägt fehl.
Vielleicht funktioniert die Datenbankverbindung, aber eine neue Migration hat einen Zustand erzeugt, mit dem eine bestimmte Funktion nicht mehr umgehen kann.
Vielleicht laufen alle Dienste, aber eine Schnittstelle liefert plötzlich ein falsches Ergebnis.
Deshalb gehören für mich neben technischen Healthchecks auch fachliche Prüfungen zum Post-Deployment-Prozess.
Nach dem Deployment brauche ich positive und negative Tests
Meine automatisierten Tests sollen ohnehin nicht nur bestätigen, dass etwas funktioniert, sondern möglichst gezielt nach Fehlern suchen. Dieselbe Haltung möchte ich auch nach einem Deployment anwenden.
Ein positiver Test könnte prüfen, ob eine zentrale Funktion tatsächlich verfügbar ist.
Ein negativer Test kann genauso wichtig sein.
Wenn eine bestimmte Funktion nach der neuen Version nur für einen festgelegten Benutzerkreis zugänglich sein darf, möchte ich nicht nur prüfen, dass der erlaubte Zugriff funktioniert. Ich möchte genauso sicherstellen, dass der unerlaubte Zugriff weiterhin blockiert wird.
Gerade Sicherheitsregeln, Berechtigungen und Abgrenzungen eignen sich dafür.
Ein Deployment kann technisch perfekt ablaufen und gleichzeitig eine Einstellung verändern, durch die plötzlich mehr Zugriff möglich ist als vorgesehen.
Das fällt bei einer reinen Erreichbarkeitsprüfung möglicherweise gar nicht auf.
Datenbankmigrationen machen das Problem besonders deutlich
Datenbankänderungen gehören für mich zu den Bereichen, bei denen ein scheinbar erfolgreiches Deployment besonders vorsichtig bewertet werden muss.
Eine Migration kann technisch durchlaufen, ohne dass dabei ein Fehler entsteht. Trotzdem kann sich erst später zeigen, dass vorhandene Daten nicht vollständig zu der neuen Struktur passen oder dass eine Anwendung an irgendeiner Stelle weiterhin von alten Annahmen ausgeht.
Deshalb sollte Codex vor einem produktiven Deployment nicht nur wissen, dass eine Migration existiert.
Es muss klar sein, welche Auswirkungen sie besitzt, ob ein Rückweg möglich ist und wie der Zustand danach geprüft werden kann.
Bei manchen Änderungen reicht vielleicht eine technische Prüfung der Tabellenstruktur.
Bei anderen brauche ich fachliche Kontrollwerte oder konkrete Testabläufe.
Auch hier gilt: Der erfolgreiche Befehl allein reicht mir nicht.
Logs gehören in die Prüfung
Ein weiterer wichtiger Bestandteil sind Logs.
Eine Anwendung kann nach außen zunächst normal wirken und gleichzeitig unmittelbar nach dem Deployment neue Fehler produzieren.
Wenn die automatische Prüfung nur fragt, ob die Webseite HTTP 200 zurückgibt, können solche Probleme leicht unbemerkt bleiben.
Deshalb möchte ich, dass Codex beziehungsweise die Deployment-Automatisierung nach einer Änderung auch relevante Logs betrachtet.
Sind neue Fehler aufgetreten?
Gibt es Exceptions, die vorher nicht vorhanden waren?
Scheitern Hintergrundprozesse?
Gibt es ungewöhnlich viele Wiederholungen oder Timeouts?
Dabei muss natürlich verhindert werden, dass jede harmlose Warnung ein Deployment automatisch als fehlgeschlagen markiert. Auch hier braucht es klare Regeln und eine vernünftige Bewertung.
Ein fehlgeschlagener Post-Deployment-Test braucht eine Konsequenz
Sobald automatische Prüfungen existieren, stellt sich zwangsläufig die Frage, was bei einem Fehler passieren soll.
Nur eine rote Meldung zu erzeugen und anschließend auf mich zu warten, wäre die einfachste Variante.
Langfristig möchte ich aber genauer unterscheiden.
Bei einem eindeutig technischen und ungefährlichen Problem kann möglicherweise automatisch reagiert werden.
Wenn beispielsweise ein Dienst nach dem Deployment nicht korrekt gestartet wurde und sich die Ursache eindeutig beheben lässt, könnte Codex einen definierten Korrekturversuch durchführen und anschließend erneut prüfen.
Bei größeren Problemen wird dagegen ein Rollback sinnvoller sein.
Und bei Situationen, in denen die Ursache nicht klar ist oder ein Rollback selbst Risiken besitzt, möchte ich bewusst selbst entscheiden.
Automatisierung bedeutet für mich nicht, dass jede Fehlerbehandlung automatisch sein muss.
Sie bedeutet, dass für die vorhersehbaren Fehler bereits ein sinnvoller Ablauf existiert.
Rollback muss vor dem Deployment gedacht werden
Ein Rückfallweg ist besonders dann wenig hilfreich, wenn man erst darüber nachdenkt, nachdem das Deployment fehlgeschlagen ist.
Deshalb sollte bereits vorher klar sein, was im schlimmsten Fall zurückgesetzt werden kann und was nicht.
Bei einem einfachen Programmstand kann das vergleichsweise unkompliziert sein.
Bei Datenbankmigrationen, veränderten Dateiformaten oder Änderungen an externen Systemen kann ein Rollback dagegen deutlich schwieriger werden.
Manche Veränderungen sind praktisch nicht vollständig rückwärts ausführbar.
Dann muss die Strategie vielleicht anders aussehen, beispielsweise durch kompatible Zwischenschritte oder eine Migration, die alte und neue Versionen für eine Übergangszeit gleichzeitig unterstützt.
Solche Entscheidungen gehören aus meiner Sicht bereits in die Planung.
Ausführliche Spezifikationen werden für mich gerade deshalb wieder wichtiger, weil Fehlerfälle und Rückwege nicht erst dann betrachtet werden sollten, wenn Codex bereits mitten in der Umsetzung steckt.
Die produktive Freigabe bleibt bei mir
So weit ich den technischen Ablauf automatisieren möchte, eine Grenze möchte ich bewusst behalten.
Das eigentliche produktive Deployment soll erst nach meiner Freigabe starten.
Codex kann alles vorbereiten, Tests durchführen, die geplanten Änderungen zusammenfassen und den Deployment-Ablauf bereitstellen. Den Schritt, der eine produktive Umgebung tatsächlich verändert, möchte ich aber weiterhin bewusst auslösen.
Das passt zu meinem Gartenstuhl-Test. Ich möchte die Freigabe theoretisch vom Smartphone aus durchführen können, aber ich möchte nicht, dass eine KI irgendwann selbst entscheidet, eine größere Änderung sei jetzt bereit für Produktion.
Die Verantwortung liegt bei mir.
Damit gehört auch diese Entscheidung weiterhin zu mir.
Automatisierung soll mir die Prüfung erleichtern, nicht die Verantwortung abnehmen
Der wichtigste Vorteil eines guten automatisierten Deployment-Prozesses wäre für mich deshalb nicht, dass ich gar nichts mehr kontrollieren muss.
Der Vorteil besteht darin, dass ich vor meiner Entscheidung bereits hochwertige Informationen bekomme und danach nicht jede technische Prüfung selbst durchführen muss.
Vor dem Deployment möchte ich wissen, was geändert wurde, welche Tests erfolgreich waren und welche bekannten Risiken bestehen.
Nach dem Deployment möchte ich eine verständliche Rückmeldung darüber erhalten, ob die erwarteten Zustände tatsächlich erreicht wurden.
Wenn etwas fehlschlägt, möchte ich nicht zuerst mehrere Systeme durchsuchen müssen, um herauszufinden, was passiert ist.
Die Automatisierung soll diese Informationen bereits zusammenführen.
Ein Deployment ist erst fertig, wenn die Software wieder verlässlich nutzbar ist
Damit verändert sich für mich auch die Definition von „fertig“.
Ein Deployment ist nicht abgeschlossen, wenn die neuen Dateien auf dem Server liegen.
Es ist nicht abgeschlossen, wenn ein Dienst neu gestartet wurde.
Und es ist auch nicht abgeschlossen, nur weil ein automatisches Skript mit Exitcode 0 geendet hat.
Fertig ist die Änderung für mich erst dann, wenn die produktive Umgebung überprüft wurde und ausreichend gute Hinweise dafür vorliegen, dass die Software tatsächlich wieder so funktioniert, wie sie soll.
Genau deshalb gehört die Post-Deployment-Prüfung für mich nicht als Zusatzfunktion hinter den eigentlichen Prozess.
Sie ist Teil des Deployments.