Was beim Deployment wirklich passiert: Artefakte in Umgebungen ausrollen

Sie haben Ihre Anwendung gebaut, Tests ausgeführt und ein verifiziertes Artefakt gespeichert. Jetzt kommt der Moment, den jeder bemerkt: das Deployment. Hier beginnt Ihre neue Version irgendwo in der realen Welt zu laufen – sei es auf einem Staging-Server für interne Tests oder in der Produktion, wo echte Nutzer darauf angewiesen sind.

Deployment bedeutet, ein Artefakt in eine Zielumgebung zu bringen und dort live zu schalten. Aber wenn Sie glauben, Deployment sei nur das Kopieren von Dateien auf einen Server, werden Sie überrascht sein. Die Art und Weise, wie Sie deployen, hängt vollständig davon ab, was Sie deployen: Anwendungscode, Datenbankänderungen oder Infrastrukturkonfiguration. Jedes hat seine eigene Mechanik, Risiken und Strategien.

Deployment ist nicht für alle gleich

Wenn Sie eine Anwendung deployen, ersetzen Sie eine laufende Version durch eine neue. Das kann bedeuten, ein neues Container-Image an Kubernetes zu senden, Binärdateien auf einem Server auszutauschen oder einen Dienst neu zu starten. Das Ziel ist einfach: die alte Version stoppen und die neue mit minimalen Unterbrechungen starten.

Datenbank-Deployment ist eine andere Herausforderung. Sie ersetzen keine Dateien; Sie führen Migrationsskripte aus, die Schemas ändern oder Daten transformieren. Eine Datenbank hält Zustände – Benutzerdatensätze, Bestellungen, Konfigurationen – die vor, während und nach der Änderung konsistent bleiben müssen. Sie können eine Datenbank nicht einfach "überschreiben", wie Sie eine JAR-Datei ersetzen. Eine Migration, die eine Spalte hinzufügt, mag sicher sein, aber eine, die eine Tabelle umbenennt, könnte jede laufende Abfrage zerstören. Und anders als Anwendungscode sind Datenbankänderungen oft irreversibel oder erfordern sorgfältige Rollback-Skripte.

Infrastruktur-Deployment fügt eine weitere Ebene hinzu. Hier wenden Sie Konfiguration auf Cloud-Anbieter oder Provisioning-Tools wie Terraform, Pulumi oder Ansible an. Das Deployment erstellt, ändert oder zerstört Ressourcen: virtuelle Maschinen, Load Balancer, Datenbanken, Netzwerkregeln. Ein Fehler im Infrastruktur-Deployment kann eine Produktionsdatenbank löschen oder sensible Daten ins Internet freigeben. Die Risiken sind hoch, und die Feedback-Schleife ist langsamer als beim Anwendungs-Deployment.

Das folgende Flussdiagramm stellt die drei Deployment-Abläufe nebeneinander dar:

flowchart TD subgraph App["Anwendungs-Deployment"] A1["Instanzen ersetzen"] --> A2["Rolling / Blue-Green / Canary"] A2 --> A3["Minimale Unterbrechung"] end subgraph DB["Datenbank-Deployment"] D1["Migrationsskripte ausführen"] --> D2["Schema ändern / Daten transformieren"] D2 --> D3["Alles-oder-nichts; Rollback nötig"] end subgraph Infra["Infrastruktur-Deployment"] I1["Konfiguration in Cloud anwenden"] --> I2["Ressourcen erstellen / ändern / löschen"] I2 --> I3["Langsames Feedback; hohes Risiko"] end

Unterschiedliche Strategien für unterschiedliche Artefakte

Da sich jeder Artefakttyp anders verhält, kann die Deployment-Strategie, die für einen funktioniert, für einen anderen ungeeignet sein.

Für Anwendungen gibt es mehrere bekannte Strategien:

Ein Kubernetes-Deployment-Manifest für ein Rolling Update könnte zum Beispiel so aussehen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
      - name: app
        image: my-app:v2.1.0
        ports:
        - containerPort: 8080
  • Rolling Update: Instanzen werden nacheinander ersetzt. Die alte Version weicht allmählich der neuen. Keine Ausfallzeit, aber alte und neue Version laufen kurzzeitig parallel.
  • Blue-Green: Eine vollständig neue Umgebung (Green) wird neben der aktuellen (Blue) aufgesetzt. Sobald die Green-Umgebung bereit und verifiziert ist, wird der gesamte Traffic umgeleitet. Sofortiger Wechsel, aber doppelte Infrastrukturkosten während des Umschaltens.
  • Canary: Die neue Version wird zunächst einer kleinen Teilmenge von Benutzern ausgeliefert. Überwachung auf Fehler oder Leistungseinbußen. Wenn alles gut aussieht, wird der Traffic schrittweise erhöht. Wenn nicht, wird der Canary zurückgezogen, ohne die meisten Benutzer zu beeinträchtigen.

Diese Strategien funktionieren, weil Anwendungsinstanzen zustandslos sind oder sich ordentlich herunterfahren lassen. Sie können mehrere Versionen gleichzeitig ausführen, ohne Daten zu beschädigen.

Datenbanken haben diesen Luxus nicht. Sie können nicht zwei Versionen eines Schemas gleichzeitig ausführen und konsistentes Verhalten erwarten. Ein Rolling Update für eine Datenbankmigration ist selten möglich, weil die Schemaänderung global ist – jede Abfrage sieht dieselbe Struktur. Canary-Deployments für Datenbanken sind ebenso knifflig. Sie könnten die Migration zuerst auf einem Replikat ausführen, aber sobald Sie es zum Primary befördern, sind alle Benutzer betroffen. Datenbankänderungen sind in der Regel Alles-oder-nichts: Sie wenden die Migration an, verifizieren sie, und wenn etwas schiefgeht, führen Sie eine Rollback-Migration aus.

Infrastruktur-Deployments liegen irgendwo dazwischen. Sie können Blue-Green für Infrastruktur verwenden, indem Sie einen parallelen Satz von Ressourcen bereitstellen und DNS- oder Load-Balancer-Ziele umschalten. Aber Infrastrukturänderungen haben oft Abhängigkeiten: Sie können keine neue Datenbankinstanz erstellen, ohne auch die Anwendungskonfiguration zu aktualisieren, die darauf verweist. Und Infrastrukturänderungen können langsam sein – die Bereitstellung eines neuen Serverclusters kann Minuten dauern, nicht Sekunden.

Zwei unverhandelbare Prinzipien

Unabhängig davon, was Sie deployen oder welche Strategie Sie wählen, gelten zwei Prinzipien für jedes Deployment.

Erstens: Deployments müssen wiederholbar sein. Wenn Sie dieselbe Pipeline zweimal mit demselben Artefakt ausführen, sollten Sie dasselbe Ergebnis erhalten. Das bedeutet, Sie müssen das bereits verifizierte Artefakt deployen, nicht zur Deployment-Zeit neu bauen. Ein Neubau führt Unsicherheit ein: Vielleicht hatte der Build-Server eine andere Bibliotheksversion, vielleicht war das Netzwerk langsam, vielleicht hat der Compiler anders optimiert. Verwenden Sie exakt dasselbe Binary, Container-Image oder Paket, das Ihre Tests bestanden hat.

Wiederholbarkeit erfordert auch, dass sich Ihre Zielumgebung in einem bekannten Zustand befindet. Wenn Sie nicht garantieren können, was bereits läuft, können Sie nicht vorhersagen, was beim Deployment passiert. Infrastructure-as-Code hilft hier: Es definiert den gewünschten Zustand Ihrer Umgebung, sodass Ihr Deployment weiß, was es erwartet.

Zweitens: Jedes Deployment muss aufgezeichnet werden. Protokollieren Sie, was deployt wurde, welche Version, welcher Commit, welche Umgebung, der genaue Zeitstempel und wer oder was es ausgelöst hat. Das ist kein Papierkram für Compliance-Prüfer. Es ist Ihre erste Verteidigungslinie, wenn etwas schiefgeht. Wenn Benutzer nach einem Deployment Fehler melden, sagt Ihnen das Deployment-Log genau, was sich geändert hat. Ohne es raten Sie nur. War es die Codeänderung? Das Konfigurations-Update? Die Datenbankmigration? Die Infrastrukturänderung? Ein gutes Deployment-Log grenzt die Suche sofort ein.

Deployment ist nicht abgeschlossen, wenn das Artefakt platziert ist

Hier ist ein häufiger Fehler: Die Pipeline markiert das Deployment als erfolgreich, sobald das Artefakt in der Umgebung landet. Aber das Platzieren des Artefakts ist nur die halbe Miete. Sie müssen verifizieren, dass die neue Version tatsächlich korrekt läuft.

Die Verifikation nach dem Deployment ist eine separate Phase. Sie prüft, ob der Dienst auf Health Checks reagiert, ob die Datenbankmigration fehlerfrei abgeschlossen wurde, ob die Infrastrukturressourcen im gewünschten Zustand sind. Einige Teams führen Smoke Tests durch – eine schnelle Reihe kritischer Benutzerreisen – um zu bestätigen, dass das Deployment nichts Offensichtliches kaputt gemacht hat.

Bis die Verifikation bestanden ist, ist das Deployment nicht abgeschlossen. Wenn die Verifikation fehlschlägt, sollte die Pipeline ein Rollback auslösen oder das Team sofort alarmieren. Darauf zu warten, dass jemand Stunden später ein Problem bemerkt, macht den Zweck der Automatisierung zunichte.

Praktische Checkliste vor Ihrem nächsten Deployment

Bevor Sie den Deploy-Button drücken oder Ihre Pipeline laufen lassen, gehen Sie diese kurze Checkliste durch:

  • Ist das Artefakt dasselbe, das alle Tests bestanden hat? (Kein Neubau zur Deployment-Zeit.)
  • Befindet sich die Zielumgebung in einem bekannten Zustand? (Keine manuellen Änderungen, die in Konflikt geraten könnten.)
  • Ist die Deployment-Strategie für den Artefakttyp geeignet? (Rolling für Apps, Migration für Datenbanken, Provisioning für Infrastruktur.)
  • Gibt es einen Rollback-Plan? (Können Sie die Änderung schnell rückgängig machen? Für Datenbanken: Haben Sie ein Rollback-Migrationsskript bereit?)
  • Wird das Deployment automatisch protokolliert? (Version, Commit, Zeitstempel, Auslöser.)
  • Gibt es einen Verifikationsschritt nach dem Deployment? (Health Checks, Smoke Tests oder Monitoring-Alarme.)

Das Fazit

Deployment ist der Moment, in dem Ihre Arbeit auf die Realität trifft. Es ist kein Dateikopiervorgang. Es ist eine sorgfältig geplante Übergabe zwischen Ihrer Pipeline und Ihrem laufenden System. Der Artefakttyp bestimmt die Strategie, der Umgebungszustand bestimmt das Risiko, und das Deployment-Log bestimmt, wie schnell Sie sich von einem Fehler erholen können. Behandeln Sie Deployment mit derselben Sorgfalt wie das Schreiben von Code – denn ein schlechtes Deployment kann Wochen guter Arbeit in Sekunden zunichtemachen.