Was Sie zuerst automatisieren sollten, wenn Ihre Deploys zu scheitern beginnen

Der Deploy-Prozess, der bei 5 Entwicklern funktioniert hat, bricht bei 15 zusammen

Jedes Engineering-Team fährt irgendwann manuelle Deploys, und eine Zeit lang funktioniert das gut. Ein oder zwei Leute kennen die Schritte, die Checkliste liegt in einem Notion-Dokument, und Releases passieren, wenn jemand einen freien Nachmittag hat. Dann wächst das Team über 15 Entwickler hinaus, die Release-Frequenz steigt von wöchentlich auf täglich, und genau derselbe Prozess fängt an, Incidents zu produzieren.

Wir sehen dieses Muster ständig: Ein Team, das zwei Jahre lang sicher ausgeliefert hat, hat plötzlich einen schlechten Monat. Nicht weil irgendjemand schlechter geworden ist – sondern weil der Prozess nie über die Teamgröße hinaus skaliert wurde, für die er ursprünglich gedacht war. Manuelle Deploys sind ein Single-Point-of-Failure-System im Kostüm von „So haben wir das schon immer gemacht.“

Die Frage, die wir gestellt bekommen, lautet nicht „Sollten wir automatisieren?“ Darüber sind sich alle längst einig. Die Frage ist, was zuerst automatisiert werden sollte – denn Teams, die versuchen, in einem Sprint alles zu fixen, bleiben meist stecken und liefern am Ende gar nichts. Hier ist die Reihenfolge, die tatsächlich funktioniert, basierend auf dem Muster, das wir bei wachsenden Teams immer wieder sehen.

Erst den Deploy-Pfad reparieren, bevor Sie die Infrastruktur anfassen

Wenn sich alles fragil anfühlt, ist der Instinkt, zuerst zu Infrastructure-as-Code zu greifen – alles mit Terraform abbilden, die Server unter Kontrolle bringen. Das ist der falsche erste Schritt. Wenn Ihr Deploy-Prozess noch immer „per SSH einloggen und ein Skript ausführen“ ist, behebt das Terraformen der Maschine, auf der das läuft, nicht den eigentlichen Fehlermodus: einen Menschen, der eine wiederholbare Aufgabe manuell erledigt, unter Zeitdruck, ohne Rollback-Plan.

Das erste Automatisierungsbudget sollte in CI/CD fließen: eine Pipeline, die bei jedem Push läuft, jedes Mal dieselben Tests ausführt und jedes Mal auf dieselbe Weise deployt. Konkret bedeutet das:

• Jeder Merge in main löst einen Build und eine Testsuite aus – keine Ausnahmen, kein „nur dieses eine Mal“ manueller Push.
• Der Deploy-Schritt ist ein Pipeline-Job, kein Terminal einer Person. GitHub Actions, GitLab CI oder CircleCI erledigen das alle; das Tool spielt eine kleinere Rolle als die Disziplin, es jedes Mal auch wirklich zu nutzen.
• Rollback ist ein Knopfdruck, keine Person, die sich um 23 Uhr an den letzten bekannten guten Commit-Hash erinnern muss.

Teams, die das zuerst umsetzen, sehen typischerweise schon im ersten Monat einen spürbaren Rückgang deploy-bezogener Incidents – ohne auch nur eine einzige Terraform-Datei anzufassen. Der Grund: Die meisten „Infrastruktur“-Incidents in dieser Phase sind gar keine Infrastrukturprobleme. Es sind Prozessprobleme im Infrastruktur-Kostüm – ein Konfigurationswert, der nur im Kopf eines Entwicklers existiert, ein Migrationsschritt, den jemand vergessen hat auszuführen, ein Deploy, das in der falschen Reihenfolge zu einem anderen passiert ist.

Dann Umgebungen reproduzierbar machen

Sobald Deploys automatisiert sind, taucht der nächste Fehlermodus auf: „Es funktioniert in Staging, aber nicht in Produktion“ oder schlimmer noch: „Wir wissen nicht mehr, wie Staging überhaupt aufgesetzt wurde.“ Genau hier verdient sich Infrastructure-as-Code seinen Platz – nicht als erste, sondern als zweite Maßnahme.

Terraform- oder OpenTofu-Module, die Ihre AWS-, GCP- oder Azure-Umgebung als versionierten Code beschreiben, lösen ein konkretes Problem: Environment Drift. Ohne IaC sammelt jede Umgebung kleine, undokumentierte Abweichungen an – hier eine manuell hochgesetzte Instanzgröße, dort eine während eines Incidents hinzugefügte Security-Group-Regel –, bis Staging keine verlässliche Vorhersage mehr für das Verhalten in Produktion liefert.

Das praktische Ziel ist nicht „100 % der Infrastruktur am ersten Tag automatisieren“. Es lautet: Können Sie Ihre Staging-Umgebung aus dem Code heraus in unter einer Stunde zerstören und neu aufbauen, ohne dass dafür Wissen nötig ist, das nur in einzelnen Köpfen steckt? Wenn die Antwort Nein ist, ist das der nächste Punkt auf der Liste – vor Kubernetes, vor Multi-Region, vor allem, was noch ambitionierter ist.

Preview-Umgebungen schließen die Lücke, die CI/CD öffnet

Sind Deploys automatisiert und die Infrastruktur reproduzierbar, ist der nächste Hebel, jedem Pull Request seine eigene Wegwerf-Umgebung zu geben. Das ist der Schritt, den Teams überspringen, weil er sich wie Luxus anfühlt – dabei ist es meist die Automatisierung mit dem größten Hebel nach den ersten beiden.

Ohne Preview-Umgebungen wird die Frage „Funktioniert das wirklich?“ in Staging beantwortet – und Staging ist geteilt, das heißt, die Änderungen aller Entwickler kollidieren miteinander. QA wird zu einer Warteschlange. Bugs werden spät gefunden, nachdem sich mehrere Änderungen bereits übereinandergestapelt haben, was sie teuer in der Isolierung macht. Preview-Umgebungen – pro Pull Request hochgefahren und beim Merge wieder abgebaut – verwandeln diese Warteschlange zurück in paralleles, unabhängiges Testen. Teams, die das nach der Reparatur der Deploy-Pipeline einführen, stellen in der Regel fest, dass sich die Zeit von Review bis Merge verbessert, weil Reviewer einen Link anklicken und die tatsächliche Änderung live sehen können, statt einen Diff zu lesen und darauf zu vertrauen.

Was zuletzt automatisiert werden sollte, nicht zuerst

Progressive Delivery – Canary Releases, Feature Flags, automatisches Rollback bei Fehlerraten-Spitzen – ist real und wertvoll, aber eine Investition für eine spätere Phase. Sie löst das Problem „Wie liefern wir sicher an Produktions-Traffic aus“, und das spielt erst eine Rolle, wenn das Ausliefern in Produktion selbst schon zuverlässig und langweilig geworden ist. Teams, die Canary-Infrastruktur bauen, bevor sie eine funktionierende CI/CD haben, automatisieren das falsche Risiko; die Traffic-Steuerungslogik hilft nichts, wenn der zugrunde liegende Deploy noch immer davon abhängt, dass jemand die richtigen Befehle in der richtigen Reihenfolge ausführt.

Kubernetes fällt für die meisten wachsenden Teams in dieselbe spätere Kategorie. Es löst echte Probleme – Autoscaling, Ressourcenisolation, selbstheilende Services –, bringt aber auch echte operative Angriffsfläche mit sich: Manifeste, Helm-Charts, Cluster-Upgrades, RBAC. Teams mit weniger als etwa 20 Entwicklern, die eine Handvoll Services betreiben, sind meist mit einer einfacheren Plattform (ECS, Cloud Run, einer gemanagten PaaS) samt solider CI/CD davor besser bedient. Wechseln Sie zu Kubernetes, wenn Sie genug Services haben, dass das Orchestrierungsproblem real ist – nicht, weil es der erwartete nächste Schritt ist.

Eine realistische Reihenfolge – und was sie kostet

Für ein Team von 15-25 Entwicklern, das von manuellen oder halbmanuellen Deploys kommt, funktioniert meist eine Reihenfolge wie diese: zuerst eine CI/CD-Pipeline mit automatisierten Tests und Ein-Klick-Rollback (typischerweise 2–4 Wochen), dann Infrastructure-as-Code für die Kernumgebungen (weitere 3–5 Wochen, abhängig davon, wie viel Drift sich bereits angesammelt hat), anschließend Preview-Umgebungen sowie Monitoring/Alerting obendrauf. Ein reines CI/CD-Setup startet typischerweise ab $8,000; die komplette Sequenz – CI/CD plus Infrastructure-as-Code plus Preview-Umgebungen – startet typischerweise ab $25,000+, abhängig davon, wie viele Services und Umgebungen im Scope sind – und es ist ein gestaffeltes Rollout, das unser Cloud & DevOps-Team Stufe für Stufe plant, statt als ein einziges, offenes Plattform-Rebuild.

Der Fehler, den es zu vermeiden gilt, ist, das Ganze als ein großes Infrastrukturprojekt mit einem einzigen Launch-Termin zu behandeln. Jede Stufe sollte unabhängig ausgeliefert werden und sich sofort auszahlen – eine funktionierende CI/CD-Pipeline ist für sich genommen wertvoll, selbst bevor Terraform im Hintergrund existiert.

Fazit

Wenn manuelle Deploys anfangen zu bröckeln, lautet die Lösung nicht „mehr DevOps-Tooling anschaffen“. Sie lautet: Reihenfolge. Erst die Pipeline, dann reproduzierbare Infrastruktur, dann Preview-Umgebungen, und Progressive Delivery sowie Orchestrierung erst, wenn die Grundlagen langweilig geworden sind. Teams, die in dieser Reihenfolge automatisieren, beheben ihre schlimmsten Incidents im ersten Monat. Teams, die mit dem ausgefeiltesten Tool auf der Liste anfangen, verbringen meist ein Quartal damit, Infrastruktur für einen Deploy-Prozess zu bauen, der darunter immer noch grundlegend manuell ist.