Wenn manuelles Deployment nicht mehr skaliert: Warum CI/CD existiert

Du behebst einen kleinen Fehler. Du baust die Anwendung auf deinem Laptop neu. Du führst Tests manuell aus – klickst dich durch dieselben Oberflächen, prüfst dieselben Ausgaben. Dann kopierst du die Build-Datei auf den Server, stoppst die laufende Anwendung, ersetzt die alten Dateien und startest neu. Wenn du einen Schritt auslässt oder die Reihenfolge durcheinanderbringst, produziert die Anwendung Fehler. Du fängst von vorne an und versuchst dich zu erinnern, wo etwas schiefgelaufen ist.

Stell dir vor, du machst das fünfmal an einem einzigen Tag. Oder stell dir ein Team von fünf Leuten vor, die das jeweils für ihre eigenen Änderungen tun. Oder eine Anwendung, die zusätzlich von einer Datenbankmigration und Infrastrukturkonfiguration abhängt. Der manuelle Prozess wird nicht nur mühsam – er wird unzuverlässig. Je häufiger du ihn wiederholst, desto größer die Wahrscheinlichkeit, dass jemand einen Schritt vergisst, Befehle in einer anderen Reihenfolge ausführt oder einen Fehler macht, weil er müde ist oder hetzt.

Das ist der Moment, in dem du nach einem besseren Weg suchst. Nicht, weil Automatisierung modern oder beeindruckend klingt, sondern weil manuelle Wiederholung nicht funktioniert, wenn Änderungen täglich oder mehrmals täglich anfallen. Du brauchst eine Möglichkeit sicherzustellen, dass bei jeder Codeänderung die Build-, Test- und Deploy-Schritte in derselben Reihenfolge mit denselben Befehlen ablaufen und dasselbe Ergebnis liefern.

Das Kernproblem: Wiederholbarkeit

Das eigentliche Problem beim manuellen Deployment ist nicht die Geschwindigkeit. Es ist die Konsistenz. Wenn du etwas von Hand machst, verlässt du dich auf dein Gedächtnis, deine Aufmerksamkeit und deine Disziplin. Das ist im großen Maßstab nicht zuverlässig. Ein müder Entwickler überspringt vielleicht einen Test. Ein gehetzter Ingenieur kopiert Dateien ins falsche Verzeichnis. Ein Teammitglied, das erst letzte Woche dazugekommen ist, kennt vielleicht nicht die genaue Schrittfolge, die alle anderen vor Monaten auswendig gelernt haben.

Diese kleinen Inkonsistenzen verursachen Probleme, die schwer zu debuggen sind. Die Anwendung funktioniert auf dem Rechner einer Person, scheitert aber auf dem Server. Die Datenbankmigration läuft zweimal, weil jemand vergessen hat, dass sie bereits ausgeführt wurde. Die Konfigurationsdatei enthält einen Tippfehler, der erst in der Produktion auffällt. Jedes dieser Probleme kostet Zeit, um es zu finden und zu beheben, und jedes untergräbt das Vertrauen in den Deployment-Prozess.

Die Lösung ist nicht, mehr Leute einzustellen, die den Prozess überprüfen. Die Lösung ist, den Prozess in etwas zu kodieren, das jedes Mal gleich abläuft – unabhängig davon, wer ihn anstößt oder zu welcher Tageszeit.

Was CI/CD eigentlich bedeutet

Das Konzept, das dieses Problem adressiert, heißt CI/CD. Aber bevor wir in die Akronyme eintauchen, hilft es, die zwei unterschiedlichen Probleme zu verstehen, die es löst.

Continuous Integration (CI) beantwortet die Frage: „Woher weiß ich, dass mein Code nach einer Änderung noch funktioniert?“ Jedes Mal, wenn du Codeänderungen pushst, nimmt ein automatisierter Prozess deinen Code, baut ihn und führt Tests aus. Wenn etwas kaputtgeht, erfährst du es sofort – nicht drei Tage später, wenn jemand anderes versucht, deinen Code zu verwenden. Das verschiebt die Feedback-Schleife von „das fangen wir beim Release auf“ zu „das fangen wir auf, wenn die Änderung gemacht wird“.

Continuous Delivery (CD) beantwortet die Frage: „Wie stelle ich sicher, dass meine Änderungen ohne manuellen Aufwand bereit für die Produktion sind?“ Jede Änderung, die die CI-Prüfungen besteht, wird verpackt und für das Deployment vorbereitet. Die eigentliche Entscheidung, in die Produktion auszuliefern, kann weiterhin manuell sein – du möchtest vielleicht eine Freigabe oder auf ein bestimmtes Zeitfenster warten. Aber die Vorbereitung ist automatisiert, sodass das Deployment eine bewusste Entscheidung und keine manuelle Tortur ist.

Es gibt auch Continuous Deployment, bei dem jede Änderung, die CI besteht, automatisch in die Produktion ausgerollt wird. Das ist eine strengere Version von CD. Es funktioniert gut für Anwendungen, bei denen die Kosten eines fehlerhaften Deployments niedrig sind und der Rollback schnell geht. Die meisten Teams beginnen mit Continuous Delivery und wechseln erst zu Continuous Deployment, wenn sie ein starkes Monitoring, schnellen Rollback und hohes Vertrauen in ihre Pipeline haben.

Die Pipeline: Dein automatisiertes Fließband

Die Reihe automatisierter Schritte, die vom Code-Push bis zum deploybaren Artefakt läuft, heißt Pipeline. Eine typische Pipeline sieht etwa so aus:

  1. Code wird in ein gemeinsames Repository gepusht.
  2. Die Pipeline holt den Code und führt einen Build aus.
  3. Unit-Tests laufen gegen die Build-Ausgabe.
  4. Integrationstests laufen gegen eine Testumgebung.
  5. Sicherheitsscans prüfen auf bekannte Schwachstellen.
  6. Der Build wird verpackt und gespeichert.
  7. Das Paket wird in eine Staging-Umgebung deployed, zur finalen Überprüfung.
  8. (Optional) Das Paket wird in die Produktion deployed – entweder automatisch oder nach manueller Freigabe.

Jeder Schritt läuft jedes Mal auf die gleiche Weise ab. Die Pipeline wird nicht müde. Sie überspringt keine Schritte, weil jemand in Eile ist. Sie vergisst die Datenbankmigration nicht, weil der Ingenieur, der sie normalerweise macht, im Urlaub ist.

Das folgende Diagramm zeigt den typischen Ablauf vom Code-Commit bis zum Deployment, mit einer Rückkopplung zum Code-Commit, wenn Tests fehlschlagen.

flowchart TD A[Code Commit] --> B[Build] B --> C[Unit Tests] C --> D{Tests Pass?} D -- No --> A D -- Yes --> E[Integration Tests] E --> F{Security Scan} F --> G[Package & Store] G --> H[Deploy to Staging] H --> I[Manual Approval?] I -- Yes --> J[Deploy to Production] I -- No --> K[Auto Deploy to Production]

Was CI/CD nicht ist

CI/CD ist kein Werkzeug. Du kannst CI/CD nicht kaufen, indem du ein SaaS-Produkt abonnierst oder einen Open-Source-Server installierst. Werkzeuge helfen dir, Pipelines zu bauen, aber der Wert entsteht daraus, wie du den Prozess gestaltest – nicht daraus, welches Werkzeug du verwendest.

CI/CD dreht sich nicht um Geschwindigkeit. Schnellere Deployments sind ein Nebeneffekt, nicht das Ziel. Das eigentliche Ziel ist Zuverlässigkeit und Konsistenz. Wenn du sicher deployen kannst, deployst du häufiger. Wenn du häufiger deployst, enthält jedes Deployment weniger Änderungen, was das Debuggen erleichtert. Geschwindigkeit folgt aus diesem Vertrauen, nicht aus der Automatisierung selbst.

CI/CD ist kein Allheilmittel. Einen schlechten Prozess zu automatisieren, lässt den schlechten Prozess nur schneller laufen. Wenn deine Tests flaky sind, wird deine Pipeline flaky sein. Wenn deine Deployment-Schritte schlecht verstanden sind, wird ihre Automatisierung diese Verwirrung festschreiben. Du musst den Prozess immer noch gut entwerfen, bevor du ihn automatisierst.

Praktische Checkliste vor dem Bau einer Pipeline

Bevor du mit dem Aufsetzen von CI/CD beginnst, prüfe diese Bedingungen:

  • Deine Tests sind zuverlässig. Wenn Tests zufällig fehlschlagen, wird die Pipeline ignoriert.
  • Dein Build-Prozess ist dokumentiert. Wenn du die Schritte nicht schriftlich beschreiben kannst, kannst du sie nicht automatisieren.
  • Deine Deployment-Schritte sind bekannt. Weißt du genau, was beim Deployment passiert? Inklusive Datenbankmigrationen, Konfigurationsänderungen und Dienstneustarts?
  • Dein Team ist sich über den Prozess einig. Automatisierung funktioniert am besten, wenn alle denselben Workflow befolgen. Wenn manche direkt auf main mergen und andere Feature-Branches verwenden, wird die Pipeline gegen die Gewohnheiten des Teams arbeiten.

Das Fazit

Manuelles Deployment funktioniert, wenn du einmal im Monat deployst und die Person, die es macht, es schon fünfzigmal gemacht hat. Es funktioniert nicht mehr, wenn Änderungen täglich kommen, das Team wächst oder die Anwendung komplexer wird. CI/CD existiert, um diese manuelle Wiederholung durch einen konsistenten, automatisierten Prozess zu ersetzen, der jedes Mal gleich abläuft. Das Ziel ist nicht, schneller zu deployen. Das Ziel ist, mit Vertrauen zu deployen – im Wissen, dass jede Änderung jedes Mal auf die gleiche Weise geprüft wurde.