CI/CD-Pipelines klingen auf dem Papier simpel: bauen, testen, ausliefern, fertig. Die Probleme, die den Deploy-Tag ruinieren, stecken fast nie im großen Ablauf — sondern in Details, die keine Doku erwähnt, weil sie zu spezifisch für eine allgemeine Anleitung sind.
Secrets-Scanning kennt keinen Kontext
Bei meiner eigenen Portfolio-Seite ist mir das kürzlich passiert: Ein Build brach ab, weil der Secrets-Scanner eine öffentliche Kontakt-E-Mail-Adresse als „Secret" erkannte — einfach, weil sie zufällig auch als Umgebungsvariable gesetzt war. Kein Leck, kein Risiko, aber ein Build, der stur nicht durchlief, bis man dem Scanner explizit sagt: dieser Wert ist öffentlich, kein Geheimnis. Die Lehre daraus: Nicht jeder rote Build-Fehler ist ein echter Fehler im Code — manchmal ist es ein Werkzeug, das zu wenig Kontext hat, und das gehört genauso zum Deployment-Alltag wie ein echter Bug.
Env-Parity ist kein Nice-to-have
Wenn lokal, Staging und Produktion unterschiedliche Node- oder PHP-Versionen, unterschiedliche Umgebungsvariablen oder unterschiedliche Cache-Konfigurationen fahren, ist jeder erfolgreiche lokale Test nur eine Vermutung über Produktion, kein Beweis. Der Aufwand, alle drei möglichst identisch zu halten, wirkt am Anfang übertrieben — bis der erste Bug ausschließlich in Produktion auftritt und niemand ihn reproduzieren kann.
Migrations und Deploy-Reihenfolge
Ob eine Datenbank-Migration vor oder nach dem Code-Deploy läuft, ist selten egal. Läuft neuer Code gegen ein altes Schema, oder altes Code gegen ein neues Schema — beides kann für Sekunden bis Minuten zu Fehlern führen, wenn man es nicht bewusst absichert (z. B. mit abwärtskompatiblen Zwischenschritten statt eines harten Schnitts).
Rollback ist eine Designentscheidung, kein Notfallplan
Die Fähigkeit, einen Deploy in einer Minute rückgängig zu machen, entsteht nicht spontan im Ernstfall — sie muss vorher eingebaut sein: alte Artefakte behalten, Migrations reversibel halten, Feature-Flags statt harter Schalter. Wer das erst beim ersten Ausfall entwirft, entwirft es unter Zeitdruck.
- Secrets-Scanner-Fehlalarme sind normal — echte Secrets vs. bewusst öffentliche Werte sauber trennen
- Lokale, Staging- und Produktionsumgebung so nah wie möglich aneinander halten
- Migrations-Reihenfolge bewusst entscheiden, nicht dem Zufall überlassen
- Rollback-Fähigkeit von Anfang an mitdenken, nicht erst beim ersten Incident
Und ganz am Ende, wenn alles grün ist: Cache-Invalidierung nicht vergessen — Build-Cache, CDN, Browser. Der häufigste Satz nach einem „erfolgreichen" Deploy ist immer noch: „Bei mir sieht es aber noch alt aus."