Was ich vor jedem Deployment checke
Eine kurze, praktische Checkliste, die mich schon öfter vor peinlichen Produktionsproblemen bewahrt hat, als ich zählen kann.
Ich habe mal an einem Freitagnachmittag die Produktion zerschossen. Eine Config-Änderung gepusht, die im Staging gut aussah, aber in einer Umgebungsvariable eine Dev-Datenbank-URL referenzierte.
Die ganze Seite war 40 Minuten down. An einem Freitag. Um 16 Uhr. Mein Handy hat nicht aufgehört zu vibrieren.
Seitdem habe ich eine Checkliste. Sie ist nicht lang. Aber ich gehe sie jedes einzelne Mal durch. Keine Ausnahmen. Auch nicht für „ist doch nur ein kleiner CSS-Fix."
Die Checkliste
1. Diff die Änderungen
Vor dem Deployment schaue ich mir genau an, was rausgeht. Nicht was ich denke, dass sich geändert hat — was sich tatsächlich geändert hat.
git diff main...HEAD
Ich vergleiche den Diff mit dem, was ich beabsichtigt hatte zu ändern. Wenn etwas im Diff ist, das ich nicht erwartet habe, stoppe ich und finde heraus, warum.
Das hat schon versehentliches Debug-Logging, übriggebliebene Testdaten und Umgebungs-Config-Änderungen aufgefangen, von denen ich nicht wusste, dass sie gestaged waren.
2. Config-Dateien validieren
JSON-Config-Dateien sind empfindlich. Ein fehlendes Komma bricht alles, und die Fehlermeldung sagt meistens etwas Nichtssagendes wie „Unexpected token."
Ich füge jede geänderte Config-Datei in einen JSON-Validator ein, bevor ich deploye. Fängt Syntaxfehler ab, die deine Augen um 16 Uhr an einem Freitag übersehen.
3. Umgebungsvariablen prüfen
Das war der Punkt, der mich erwischt hat. Staging und Produktion sehen gleich aus, aber die Umgebungsvariablen sind unterschiedlich. Datenbank-URLs, API-Keys, Feature-Flags — wenn irgendwas davon falsch ist, kann es zu stillen Fehlern führen, die schwer nachzuverfolgen sind.
Ich führe eine Checkliste mit Umgebungsvariablen, die sich zwischen Umgebungen unterscheiden, und verifiziere jede einzelne. Mühsam? Ja. Besser als die Produktion runterzureißen? Auch ja.
4. Den kritischen Pfad testen
Ich lasse nicht die komplette Testsuite vor jedem Deploy laufen (dafür ist die CI da). Aber ich teste manuell den kritischen Benutzerpfad:
- Kann sich ein Benutzer registrieren?
- Kann er sich einloggen?
- Kann er die Hauptfunktion unseres Produkts nutzen?
- Kann er uns bezahlen?
Wenn irgendetwas davon nicht funktioniert, ist alles andere irrelevant.
5. Asset-Größen prüfen
Bevor ich Frontend-Änderungen shippe, schaue ich, ob neue Assets unverhältnismäßig groß sind. Ein unkomprimiertes Bild oder ein nicht-minifiziertes JavaScript-Bundle kann deine Ladezeit über Nacht ruinieren.
Schnelle Checks:
- Kein Bild über 200KB (es sei denn, es gibt einen guten Grund)
- CSS und JS sind minifiziert
- Keine neuen Fonts versehentlich hinzugefügt
6. Den Rollback-Plan verifizieren
Kann ich dieses Deployment schnell rückgängig machen, wenn etwas schiefgeht?
Bei den meisten Projekten ist das git revert und erneut deployen. Aber wenn das Deployment Datenbank-Migrationen beinhaltet, ist der Rollback komplexer. Kenne das vor dem Deploy, nicht während des Incidents.
Was nicht auf meiner Liste steht
Beachte, was fehlt:
- Alle Tests laufen lassen — Die CI erledigt das. Wenn Tests in der CI bestehen, vertraue ich ihnen.
- Code Review — ist schon vor dem Merge passiert. Keine Deploy-Zeit-Aktivität.
- Dokumentation aktualisieren — wichtig, aber kein Blocker fürs Deployment.
Die Deploy-Checkliste geht speziell um „wird das die Produktion kaputt machen?" Nicht um Codequalität, Dokumentation oder Prozess. Das ist auch alles wichtig, aber es passiert früher.
Die Freitags-Regel
Ich deploye freitagnachmittags nicht mehr. Wenn etwas kaputtgeht, will ich einen vollen Arbeitstag zum Fixen, nicht ein Wochenende voller Angst.
Montag bis Donnerstag, während der Arbeitszeiten. Das ist mein Deployment-Fenster. Ausnahmen gibt es, aber sie sind selten und bewusst.
Eine Checkliste ist nicht aufregend. Niemand schreibt Blogposts über seine Deployment-Checkliste und wird damit berühmt. Aber der Zweck einer Checkliste ist nicht, interessant zu sein — sie soll die eine Sache auffangen, die du vergessen hast. Und sie muss dich nur einmal retten, um die zwei Minuten wert zu sein, die sie kostet.