Deployment-Checkliste
Deployment-Checkliste für kleine Software-Teams: Vorabprüfung, Rollout, Verifikation und Rollback als Vorlage, direkt aus der CI-Pipeline startbar.
- Typischer Rhythmus pro Deployment
- Die Checkliste 5 Abschnitte, 24 Punkte
- Variablen
{{service}}{{version}}{{environment}} - Aus der CI starten
Diese Checkliste gehört zu jeder Änderung, die in eine gemeinsam genutzte Umgebung geht. Das ist in erster Linie Produktion, aber auch eine Staging-Umgebung, gegen die andere Teams testen. Sie passt zu Teams, die oft genug deployen, um einen Schritt zu vergessen, aber nicht so oft, dass bereits alles automatisiert ist.
Wer verantwortlich ist
Wer das Deployment auslöst, ist für den Durchlauf verantwortlich. Diese Person muss nicht jeden Schritt selbst erledigen. Sie entscheidet aber, ob das Deployment stattfindet, und bleibt erreichbar, bis die Prüfungen danach abgeschlossen sind. Schritte wie das Review einer Migration werden im Durchlauf direkt der zuständigen Person zugewiesen. So zeigt das Protokoll später, wer was bestätigt hat.
Typische Fehler
- Rollback erst planen, wenn es brennt. Den genauen Rollback-Befehl vorher notieren und prüfen, ob das vorherige Artefakt noch existiert.
- Migrationen ohne Rückweg. Schemaänderungen so bauen, dass die laufende Version damit weiter funktioniert. Alte Spalten erst in einem späteren Release entfernen.
- "Ist doch grün." Ein Health-Check zeigt nur, dass der Prozess läuft. Fehlerraten und einen echten Nutzerablauf prüfen.
- Deployen am Freitagnachmittag. Keine Deployments kurz vor Feierabend, vor dem Wochenende oder wenn niemand da ist, der die Änderung kennt.
Am einfachsten startet die Pipeline den Durchlauf, sobald ein Release-Tag gepusht wird. Dann liegt die Checkliste bereit, bevor jemand anfängt, und jedes Deployment hinterlässt einen nachvollziehbaren Eintrag.
Die Checkliste: Deployment {{service}} {{version}} nach {{environment}}
Vor dem Deployment
-
Release Notes oder Changelog für
{{version}}geschrieben und verlinktTicket-Links und alles aufführen, was das Verhalten für Nutzer oder andere Services ändert.
-
CI-Pipeline auf genau dem Commit grün, der deployt wird
-
Änderung von jemand anderem als dem Autor geprüft und freigegeben
-
Datenbankmigrationen geprüft und abwärtskompatibel zur laufenden Version
Neuer Code muss mit dem alten Schema funktionieren und alter Code mit dem neuen. Nur dann bleibt ein Rollback möglich.
-
Neue Konfigurationswerte und Secrets in
{{environment}}angelegt -
Rollback-Plan notiert: Befehl, vorherige Versionsnummer, wer entscheidet
-
Vorheriges Artefakt oder Image für den Rollback noch verfügbar
-
Zeitfenster abgestimmt, keine parallelen Deployments oder Wartungen geplant
-
Aktuelles Backup oder Snapshot der Datenbank bestätigt optional
Lohnt sich vor riskanten Migrationen. Bei zustandslosen Änderungen überspringen.
Kommunikation
-
Team-Channel informiert, dass das Deployment von
{{service}}startet -
Support und kundennahe Teams über sichtbare Änderungen informiert optional
-
Wartungshinweis auf der Statusseite veröffentlicht, falls Ausfallzeit zu erwarten ist optional
Deployment durchführen
-
Feature-Flags für unfertige Funktionen in
{{environment}}ausgeschaltet -
Migrationen ausgeführt und Ausgabe auf Fehler geprüft
-
Neue Version
{{version}}ausgerolltWenn die Plattform es erlaubt, schrittweise ausrollen: erst eine Instanz oder ein Canary, dann der Rest.
-
Alle Instanzen melden die neue Version und sind gesund
Prüfen
-
Smoke-Test des wichtigsten Nutzerablaufs bestanden (Login, Kernfunktion, Zahlung falls relevant)
-
Fehlerrate und Latenz in den Dashboards 15 Minuten lang unauffällig
-
Keine neuen Fehlertypen in den Logs
-
Hintergrundjobs, Queues und geplante Tasks laufen
-
Neue Funktionen verhalten sich in
{{environment}}wie erwartet
Abschluss
-
Team-Channel aktualisiert: Deployment abgeschlossen oder mit Begründung zurückgerollt
-
Tickets auf erledigt gesetzt und Release im Issue-Tracker markiert
-
Nacharbeiten als Tickets erfasst (Aufräum-Migrationen, Flags entfernen, Lücken im Monitoring)
Checkliste als Markdown
Diese Checkliste aus der Pipeline starten
Bei einem gepushten Tag POST /api/v1/runs mit der Vorlage "Deployment {{service}} {{version}} nach {{environment}}" und dem Tag als version aufrufen.
curl -X POST https://runbook.metastic.ch/api/v1/runs \
-H "Authorization: Bearer $RUNBOOK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template": "Deployment {{service}} {{version}} nach {{environment}}", "variables": {"service": "…", "version": "…", "environment": "…"}}'Häufige Fragen
Was ist der Unterschied zwischen Deployment-Checkliste und Release-Checkliste?
Die Deployment-Checkliste deckt den technischen Vorgang ab: eine Version in eine Umgebung bringen, prüfen und notfalls zurückrollen. Die Release-Checkliste deckt das Ereignis drumherum ab, also Ankündigung, Dokumentation und Vorbereitung des Supports. Viele Teams nutzen beide, und ein Release kann mehrere Deployments umfassen.
Braucht man eine Checkliste, wenn CI/CD alles automatisiert?
Die Pipeline nimmt die meisten manuellen Schritte ab, aber nicht die Entscheidungen. Ist die Migration sicher? Ist jemand da, der beobachtet? Weiß der Support Bescheid? Für Routine-Deployments die Liste kurz halten und aufwendige Schritte als optional markieren, damit sie sichtbar bleiben, ohne zu blockieren.
Wie startet man die Checkliste automatisch aus der CI?
In Runbook ein API-Token anlegen und in der Pipeline einen Schritt ergänzen, der POST /api/v1/runs mit dem
Vorlagennamen und den Variablen service, version und environment aufruft. Der Durchlauf erscheint dann mit
der richtigen Version, und der Link lässt sich automatisch in den Team-Chat posten.
Aktualisiert