Die Resonanz auf den ersten Beitrag hier war bislang sehr erfreulich. Gleichzeitig gab es auch konstruktive Kritik, für die ich mich besonders bedanken möchte. Insbesondere Frank Geisler (twitter/www) hat mich freundlicherweise darauf hingewiesen, dass die Tatsache, dass CI/CD gerade im Datenbank-Umfeld besonders schwierig ist nochmal eine besondere Erwähnung und Erklärung verdient.
Die Sache mit den fehlenden Tools
Da CI/CD in erster Linie der Software-Entwicklung entstammt, sind die meisten vorhandenen Tools genau auf Prozesse der Software-Entwicklung abgestimmt. Schnell durchzuführende, schlanke Unit-Tests, die ein effizientes Testen weiter Teile des Codes ermöglichen sind in die Prozesse fest eingeplant. Wer schon einmal versucht hat, Datenbank-Entwicklungen, Analysis Services Cubes oder ETL-Strecken systematisch zu testen, der wird festgestellt haben, dass hier zwar tools existieren, diese Tools aber oftmals die Qualität und den Umfang der Test-Frameworks aus dem Development-Bereich vermissen lassen.
Darüber hinaus lassen sich viele Änderungen nicht isoliert testen. Ein neues Feld in der Datenbank lässt sich am sinnvollsten testen, wenn gleichzeitig die Ladestrecke getestet wird, die das Feld füllen soll und der Cube, der es als Measure oder Dimensions-Attribut anzeigt und idealerweise auch noch der Bericht, der dieses Feld verwendet. Jeder dieser Tests ist isoliert betrachtet zwar möglich aber nur das Zusammenspiel aller Komponenten ermöglicht den Test der Business-Logik, für die das Feld angelegt wurde.
Und selbst wenn wir ein Tool hätten, mit dem wir sinnvoll eine Änderung testen könnten, liegt die Aufbereitungszeit für ETL-Strecken oder gar Cubes üblicherweise nicht im Sekunden-Bereich sondern kann sogar Stunden dauern, was den Prinzipien der schlanken, in die Pipeline integrierten Tests diametral entgegen steht.
Wir können an dieser Stelle also noch einmal betonend festhalten, dass gerade im Datenbank- und BI-Umfeld die Tool-Landschaft eher dünnbesiedelt ist (einige Tools werden wir hier später noch vorstellen), gleichzeitig die Frage, wie was zu testen ist sich nicht so einfach beantworten lässt. Der CI-Schritt einer CI/CD-Umgebung ist damit hier wirklich ein komplexes Thema.
Die Sache mit den Kosten
Einen BI-Stack zu lizensieren ist nie eine ganz kostengünstige Angelegenheit. Die anfallenden Lizenzkosten können durchaus signifikant sein. Daher scheuen viele Unternehmen die Kosten, um sich ein zweites System zu lizensieren, das die meiste Zeit brach liegt und nur für (automatisierte) Tests der Entwicklungen Verwendung findet.
Hier können zum Glück moderne Architekturen, die Cloud-Services einbeziehen Abhilfe schaffen, doch sind die entsprechenden Plattformdienste teilweise auch noch nicht so lange verfügbar und müssen nach dem Deployment zunächst mit Daten gefüllt werden, was je nach Umfang der Tests länger dauern kann und damit auch wiederum Kosten verursacht.
Die Sache mit den Daten
Beim automatisierten Deployment ist wichtig, dass eine vollständige Funktionalität der Lösung nach dem Deployment sichergestellt ist. Im Falle einer Datenbanklösung bedeutet das, dass das Deployment auf keinen Fall einen Datenverlust verursachen darf.
Diesen Punkt kann man gar nicht genug betonen, denn (nahezu) alle Schema-Änderungen sind potenziell „breaking changes“. Eine Änderung eines Feldes von varchar(100) auf varchar(50) kann in jeder Dev- und Testumgebung vollkommen harmlos sein. Wenn hierdurch in der Live-Umgebung Daten abgeschnitten werden, so sind diese für immer verloren. Im Gegensatz zu Software ist ein einfacher „Rollback“ auf die vorherige Version nicht möglich ohne das Einspielen eines Datenbank-Backups, was wiederum bedeutet, alle Transaktionen seit der Änderung des Feldes wieder durchführen zu müssen.
Schema-Änderungen an Datenbanken sind deshalb klassich manuelle Prozesse, die von Experten geprüft und unter größter Vorsicht durchgeführt werden. Diesen Prozess zu automatisieren birgt große Risiken, da nicht jede automatische Lösung hier ein konservatives Vorgehen wählt, das eine Datensicherheit gewährleistet.