Warum Database Deployments eine eigene Strategie brauchen

Sie haben eine CI/CD-Pipeline, die für Ihre Anwendung einwandfrei funktioniert. Codeänderungen werden in Minuten gebaut, getestet und in Produktion deployed. Das Team liefert mehrmals täglich aus, ohne ins Schwitzen zu kommen. Dann fügt jemand eine Datenbankmigration in dieselbe Pipeline ein – und alles bricht zusammen.

Die Migration läuft fünfundvierzig Minuten auf einer großen Tabelle. Während dieser Zeit ist die Tabelle gesperrt. Benutzer sehen Fehler. Die Anwendung kann keine Anfragen mehr bedienen. Auf halbem Weg schlägt die Migration fehl, aber ein sauberer Rollback ist unmöglich, weil einige Zeilen bereits verändert wurden. Die Pipeline, die früher fünf Minuten dauerte, braucht jetzt eine Stunde, und niemand wagt es, sie während der Geschäftszeiten auszuführen.

Das ist kein Tool-Problem. Es ist ein Strategie-Problem. Database Deployments unterliegen grundlegend anderen Zwängen als Application Deployments. Werden sie gleich behandelt, entstehen Risiken, die keine noch so gute Automatisierung beheben kann.

Das Application-Deployment-Muster, das nicht übertragbar ist

Application Deployments folgen einem einfachen, wiederholbaren Muster: eine neue Version bauen, auf Servern deployen und bei Problemen auf die vorherige Version zurückrollen. Dieser Zyklus kann sich mehrfach täglich wiederholen, mit minimalen Konsequenzen. Die alte Version ist noch da. Die Dateien sind noch gültig. Der Rollback bedeutet nur, den Load Balancer wieder auf das vorherige Release zu richten.

Database Deployments funktionieren nicht so. Wenn Sie eine Migration ausführen, verändern Sie Datenstrukturen, die bereits Produktionsdaten enthalten. Ein Rollback ist kein einfacher Schalter. Sie können eine neu hinzugefügte Spalte nicht einfach „undeployen“ oder eine gelöschte Tabelle wiederherstellen, ohne den vorherigen Zustand sorgfältig zu rekonstruieren. Daten, die während der Migration transformiert wurden, kehren nicht automatisch zurück.

Das folgende Flussdiagramm stellt die beiden Zyklen gegenüber:

flowchart TD subgraph App[Application Deployment] A1[Build] --> A2[Deploy] A2 --> A3{Erfolg?} A3 -->|Ja| A4[Fertig] A3 -->|Nein| A5[Rollback: Load Balancer umstellen] A5 --> A2 end subgraph DB[Database Deployment] B1[Migrieren] --> B2[Tabelle sperren] B2 --> B3[Daten transformieren] B3 --> B4{Erfolg?} B4 -->|Ja| B5[Fertig] B4 -->|Nein| B6[Rollback: Daten rekonstruieren] B6 --> B1 end

Der Zeitfaktor verschärft das Problem. Application Deployments sind normalerweise in Sekunden oder Minuten abgeschlossen. Datenbankmigrationen auf großen Tabellen können Dutzende Minuten oder Stunden dauern. Während dieser Zeit können Tabellen gesperrt, Abfragen blockiert und die Anwendung teilweise oder vollständig unerreichbar sein. Eine Pipeline, die Datenbankänderungen nur als einen weiteren Schritt im Anwendungs-Workflow behandelt, ignoriert diese Realitäten.

Warum die Trennung der Pipelines sinnvoll ist

Die praktischste Antwort auf dieses Missverhältnis ist die Trennung der Application-Pipeline von der Database-Pipeline. Sie laufen mit unterschiedlichen Zeitplänen, unterschiedlichen Review-Prozessen und unterschiedlichen Risikoprofilen.

Die Application-Pipeline bleibt schnell. Sie liefert weiterhin mehrmals täglich Features, Bugfixes und Konfigurationsänderungen aus. Die Database-Pipeline läuft in einem langsameren Rhythmus, mit sorgfältigerer Prüfung und expliziter Terminierung. Datenbankmigrationen können mehrere Zyklen vor dem Application Deployment ausgeführt werden, das von ihnen abhängt. Das schafft einen Puffer: Wenn die Migration Probleme macht, bleibt Zeit für Korrekturen, ohne das Anwendungs-Release zu blockieren.

Diese Trennung ändert auch die Zuständigkeiten. Application Deployments liegen normalerweise in der Verantwortung des Entwicklungs- oder Plattformteams. Database Deployments erfordern oft die Beteiligung eines DBAs oder eines Teammitglieds, das das Schema, das Datenvolumen und das Sperrverhalten der Migration versteht. Eine separate Pipeline macht klar, wer welche Art von Änderung prüfen, genehmigen und überwachen muss.

Rückwärtskompatible Schemaänderungen reduzieren Risiken

Eine weitere Strategie, die die Denkweise über Database Deployments verändert, ist die Rückwärtskompatibilität von Schemaänderungen. Die Idee ist einfach: Das alte und das neue Schema sollten für eine gewisse Zeit koexistieren können. So können Sie die Anwendung und die Datenbankänderungen in separaten Schritten deployen, ohne einen synchronisierten Cutover zu benötigen.

Betrachten wir das Umbenennen einer Spalte. Der naive Ansatz ist, die Spalte in einer Migration umzubenennen und gleichzeitig den Anwendungscode anzupassen. Wenn etwas schiefgeht, bricht die Anwendung, weil sie auf einen Spaltennamen verweist, der nicht mehr existiert.

Ein rückwärtskompatibler Ansatz sieht anders aus. Zuerst wird die neue Spalte hinzugefügt, während die alte erhalten bleibt. Die Anwendung wird aktualisiert, um in beide Spalten zu schreiben. Dieser Change wird deployed. Sobald Sie sicher sind, dass alles funktioniert, wird die Anwendung aktualisiert, um aus der neuen statt der alten Spalte zu lesen. Erneutes Deployment. Schließlich, nachdem alle Konsumenten migriert sind, wird die alte Spalte in einer separaten Migration entfernt.

Dieser Prozess dauert länger. Er erfordert mehrere Deployments und mehr Koordination. Aber er ist deutlich sicherer. Wenn in einem Schritt etwas schiefgeht, können Sie die Anwendung zurückrollen, ohne die Datenbank in einem inkonsistenten Zustand zu hinterlassen. Die Datenbankänderungen sind nie der Blockierer.

Governance ist keine Bürokratie, sondern Schutz

Datenbankänderungen brauchen einen Review-Prozess, der über die reine Syntaxprüfung hinausgeht. Ein Pull Request für eine Migration sollte Antworten auf Fragen enthalten wie: Wird diese Migration die Tabelle sperren? Wie lange wird die Sperre voraussichtlich dauern? Wie hoch ist die geschätzte Ausführungszeit auf dem Produktionsdatenvolumen? Gibt es andere Dienste oder Konsumenten, die aus dieser Tabelle lesen und betroffen sein könnten?

Hier geht es nicht um zusätzliche Bürokratie. Es geht darum, anzuerkennen, dass Datenbankänderungen Konsequenzen haben, die Codeänderungen nicht haben. Ein Bug im Anwendungscode kann mit einem neuen Deployment behoben werden. Ein Bug in einer Migration kann Daten korrumpieren, Ausfallzeiten verursachen oder eine Wiederherstellung aus dem Backup erforderlich machen. Der Review-Prozess dient dazu, diese Risiken zu erkennen, bevor sie die Produktion erreichen.

Das gleiche Prinzip gilt für die Frage, wer Migrationen ausführen darf. Nicht jeder sollte die Berechtigung haben, Schemaänderungen in der Produktion durchzuführen. Das ist keine Frage des Vertrauens. Es geht um Verantwortlichkeit und die Tatsache, dass Datenbankänderungen spezifisches Wissen über Datenvolumen, Indizierung, Sperrverhalten und Replikationsverzögerung erfordern. Eine separate Pipeline mit kontrolliertem Zugriff und expliziten Genehmigungsschritten ist eine praktische Sicherheitsmaßnahme, keine bürokratische Hürde.

Was das für Ihr Team bedeutet

Wenn Ihr Team Datenbankmigrationen nur als einen weiteren Schritt in der Application-Pipeline behandelt, tragen Sie unnötige Risiken. Die Lösung ist nicht, Application Deployments zu verlangsamen. Es geht darum, Database Deployments eine eigene Strategie, eine eigene Pipeline und einen eigenen Review-Prozess zu geben.

Beginnen Sie mit der Trennung. Führen Sie Application- und Database-Pipelines unabhängig voneinander aus. Machen Sie Schemaänderungen wann immer möglich rückwärtskompatibel. Bauen Sie einen Review-Prozess auf, der die richtigen Fragen zu Sperrverhalten, Zeitplanung und Konsumentenauswirkungen stellt. Und akzeptieren Sie, dass Database Deployments niemals so schnell oder beiläufig sein werden wie Application Deployments. Das ist keine Einschränkung. Es ist eine Anerkennung dessen, was auf dem Spiel steht.

Praxis-Checkliste für die Database-Deployment-Strategie

  • Application- und Database-Pipelines sind getrennt, mit unterschiedlichen Zeitplänen und Review-Prozessen
  • Schemaänderungen sind wo möglich rückwärtskompatibel ausgelegt
  • Jede Migration enthält eine geschätzte Ausführungszeit und eine Sperranalyse
  • Datenbankänderungen durchlaufen einen Pull-Request-Review mit expliziten Prüfungen auf Tabellensperren und Konsumentenauswirkungen
  • Migrationen werden in einer Staging-Umgebung mit produktionsähnlichem Datenvolumen getestet
  • Ein Rollback-Plan wird dokumentiert, bevor eine Migration in der Produktion ausgeführt wird

Das Fazit

Database Deployment ist kein technisches Problem, das man durch Hinzufügen eines Migrationstools zur bestehenden Pipeline lösen kann. Es ist ein Strategie-Problem, das einen separaten Prozess erfordert – mit anderem Timing, anderen Review-Kriterien und einer anderen Risikotoleranz. Teams, die das so handhaben, liefern langfristig schneller aus, weil sie nicht mehr von Datenbankänderungen blockiert werden, die nie dafür gemacht waren, in eine Application-Pipeline zu passen.