Ein Datenbank-Deployment kann in CI/CD technisch „rot“ sein und trotzdem bereits Änderungen in der Datenbank hinterlassen haben. Der Grund: Oracle behandelt DDL anders als normales transaktionales DML. Wer in einem Shell-Skript einfach ROLLBACK ergänzt, hat deshalb noch keine Wiederherstellung gebaut.
CREATE, ALTER oder DROP wird dadurch nicht ungeschehen.Warum DDL nicht transaktional zurückgeht
Oracle führt vor und nach DDL-Anweisungen implizite Commits aus. Ein Skript kann also erfolgreich eine Tabelle ändern, anschließend bei einem weiteren Schritt scheitern und mit ROLLBACK nur noch nicht bestätigte DML-Arbeit verwerfen. Die vorherige Strukturänderung bleibt bestehen. Eine Pipeline muss daher Deployment-Fehler erkennen und einen separaten, ausdrücklich geplanten Wiederherstellungsweg besitzen.
SQLcl muss Fehler zuverlässig an die Pipeline melden
Bei nicht-interaktiven Läufen sollten SQLcl-Skripte SQL- und Betriebssystemfehler als Prozessfehler zurückgeben. Eine SQL-Fehlerbehandlung kann beispielsweise so aussehen:
WHENEVER SQLERROR EXIT SQL.SQLCODE ROLLBACK
WHENEVER OSERROR EXIT 9 ROLLBACK
-- Deploymentschritte ausführen
lb update -changelog-file controller.xml
EXIT 0Die CI-Plattform muss den Exit-Code des SQLcl-Prozesses prüfen und den Lauf bei einem Fehler stoppen. Zugangsdaten gehören in den Secret Store des CI-Systems oder in eine geeignete externe Passwortverwaltung – nicht in das Repository, in Kommandozeilen-Logs oder in ein mit set -x protokolliertes Shell-Skript. Für automatisierte Verbindungen sollte ein getestetes, nicht-interaktives Authentifizierungsverfahren genutzt werden.
Rollback als eigener Deployment-Schritt
Liquibase kann Änderungen anhand des Changelogs bis zu einem gesetzten Tag zurückrollen. Das funktioniert aber nur, wenn die Changesets passende Rollback-Anweisungen enthalten oder Liquibase sie für den jeweiligen Änderungstyp sicher ableiten kann. Ein Tag ist ein Bezugspunkt in der Liquibase-Historie – kein Datenbank-Snapshot und keine Sicherung der Nutzdaten.
Ein belastbarer Ablauf sieht deshalb so aus:
- Vor dem Release Changelog und generiertes SQL prüfen; in einer Testumgebung Deployment und Rückweg mit repräsentativen Daten ausführen.
- Direkt vor der Änderung einen eindeutigen Liquibase-Tag setzen, zum Beispiel mit der Pipeline- oder Release-ID.
- Änderungen anwenden und anschließend Schema-, Anwendungs- und Integrationsprüfungen ausführen.
- Bei einem Fehler den Lauf anhalten und nur dann einen automatischen Liquibase-Rollback starten, wenn dieser Pfad für alle betroffenen Changesets getestet und freigegeben ist.
- Wenn Änderungen nicht reversibel sind, einen dokumentierten Vorwärtsfix oder einen Backup-/Restore-Plan verwenden und eine automatische Wiederholung verhindern.
Gerade Datenmigrationen verdienen besondere Aufmerksamkeit: Ein UPDATE, das viele produktive Werte überschreibt, lässt sich nicht durch ein strukturelles DDL-Rollback wiederherstellen. Für solche Schritte braucht es je nach Risiko eine Gegenmigration, eine gesicherte Ausgangskopie oder einen bewusst geplanten Vorwärtsfix.
Pipeline in klare Qualitätsstufen aufteilen
Praktisch bewährt sich eine Trennung aus Pull-Request-Prüfung, Deployment nach Test, automatisierten Smoke-Tests und einem freizugebenden Produktionsschritt. Changelog-Status und geplanter SQL-Output werden vorab geprüft; nach dem Deployment kontrollieren Tests nicht nur den SQLcl-Exit-Code, sondern auch zentrale Datenbankobjekte und den relevanten Anwendungspfad. Logs sollten Release-ID, Change-Set und Ergebnis enthalten, aber keine Secrets.
Fazit
Ein CI/CD-System kann Fehler sauber erkennen – es kann Oracle-DDL jedoch nicht durch ein gewöhnliches Transaktions-ROLLBACK zurückzaubern. Nutzen Sie SQLcl-Fehlercodes zur zuverlässigen Pipeline-Steuerung und behandeln Sie Liquibase-Rollbacks als getestete Deployment-Strategie, nicht als Notfallknopf. Für nicht reversible Änderungen muss der Wiederherstellungsplan vor dem Produktionslauf feststehen.
Weiterführend: Oracles Dokumentation zu SQL-Anweisungstypen und impliziten DDL-Commits, zu SQLcl WHENEVER und zu Liquibase-Befehlen in SQLcl.