Die Frage nach dem richtigen Werkzeug
Wenn sich IT-Anwender mit dem Deployment von Datenbanken auseinandersetzen, kommt sehr schnell die Frage auf, mit welchen Werkzeugen die dabei entstehenden Probleme minimiert werden können. Oft wird das Thema dadurch akut, dass das Deployment der Datenbank eine Schwierigkeit bei der Einführung einer Continuous Delivery Pipeline darstellt. Die Frage nach der richtigen Toolunterstützung wird natürlich auch an uns als Berater herangetragen.
Die richtige Deployment-Strategie
Bevor man sich jedoch für ein Tool entscheiden kann, muss man sich zunächst über die Vorgehensweise im Klaren sein. Hier gibt es 2 grundlegend verschiedene Ansätze.
- Die klassische Vorgehensweise („old school“):
Wir bringen die Produktions-DB in genau den Zustand, indem sich die Abnahme-DB beim Abnahmetest befunden hat. Mit anderen Worten: wir vergleichen 2 Datenbanken, ermitteln das Delta und deployen die erstellten update-Skripte. - Die agile Vorgehensweise („new school“):
Die Idee des Agile Database Development betrachtet die Datenbank als Teil der Anwendung. Demzufolge sollten Datenbankänderungen, die zur Codeänderungen benötigt werden, auch als Skripte hinterlegt und zusammen mit dem Code im Sourcecode-Repository verwaltet werden.
Der agile Ansatz zeichnet sich dadurch aus, dass die Entwickler die Besitzer der Datenbank sind. Beim klassischen Ansatz wird eher eine Vorgehensweise unterstützt, bei der die Entwickler neue Datenbank-Tabellen beim DBA beantragen, der dann „aus einer Hand“, die Test-, Abnahme-, oder Produktionsumgebung bereitstellt.
Marktübliche Tools
Tools, die den klassischen Ansatz unterstützen, werden auch als Compare & Sync „“ Tools bezeichnet. Beispiele dafür sind Regdate oder DBMaestro.
Bekannte Werkzeuge, die einen agilen Ansatz unterstützen, sind z. B. Liquibase oder Flyway. Mit ihnen ist es möglich, Skripte für verschiedene Zielumgebungen zu verwalten, und nachzuhalten, welche Skripte auf welchen Umgebungen schon gelaufen sind. Diese Form der skriptbasierten Datenbankentwicklung hat jedoch 2 Nachteile. Zum einen muss man manuell Update-Skripte erstellen, die voraussetzen, dass sich die Zieldatenbank vor dem Deployment tatsächlich in dem erwarteten Zustand befunden hat. Zum anderen ergibt sich der aktuelle Zustand der Datenbank nur aus der Summe aller Update-Skripte. Es gibt immer noch keine Dateien in unserem Sourcecode-Repository, die allein für sich den Zustand der Datenbanktabellen zu einer beliebigen Softwareversion darstellen würden.
Es geht auch anders
Dieses Problem wird dadurch gelöst, dass wir in unserem Sourcecode-Repository Skripte verwalten, die den Soll-Zustand der Datenbank beschreiben und nicht nur das Delta zur letzten Version. Um mit solchen Skripten Datenbankänderungen deployen zu können, benötigt man ein Framework, das das Delta zum Ist-Zustand der Datenbank selbst ermittelt und die benötigten Update-Skripte generiert. Damit ist es auch egal, in welchem Zustand sich die Zieldatenbank vorher befunden hat, es wird in jedem Fall der Soll-Zustand hergestellt.
Vor einiger Zeit habe ich an dieser Stelle unser Framework Orcas vorgestellt, mit dem dieser Ansatz konsequent umgesetzt werden kann. Orcas ist als Open Source erhältlich und beinhaltet die Definition einer domänenspezifischen Sprache, in der die zu realisierenden Datenbankobjekte beschrieben werden. Durch Abgleich mit dem Data Dictionary der Oracle Datenbank, auf die die Anwendung von Orcas beschränkt ist, erkennt Orcas die Abweichungen zwischen Soll- und Ist-Zustand, generiert die benötigten Update-Skripte und führt diese aus. Einen Überblick über die Funktionsweise und Möglichkeiten von Orcas findet sich in unserem kürzlich erschienen Whitepaper. Eine ausführliche Dokumentation mit Beispielen und einer genauen Installationsanleitung findet man im Orcas-Projekt auf Github.
Fazit
Wie man sieht, kann es beim Deployen der Datenbank nicht nur darum gehen, ein Tool zur Unterstützung der Entwickler zu beschaffen. Zunächst sollte man sich überlegen, welche Vorgehensweise zur eigenen Organisation passt, bzw. welche Vorgehensweise man zukünftig im Unternehmen umsetzen möchte. Erst dann erst sollte sich man nach einem passenden Tool umsehen. Der Markt bietet hier Alternativen, die ohne hohe Lizenzkosten professionelle Lösungen ermöglichen.
