In diesem Beitrag wollen wir nicht nur die Begrifflichkeiten von Continuous Integration und Continuous Delivery (CI/CD) erklären, sondern uns auch Gedanken zu deren grundsätzlicher Anwendung im Datenbanken und BI-Umfeld machen. Damit dient dieser Beitrag sozusagen als Grundlagen-Kapitel zu den Beiträgen, die wir hier zum Thema CI/CD veröffentlichen werden.

CI, was ist das eigentlich?

Wikipedia definiert Continuous Integration (CI) relative nüchtern als Prozess des fortlaufenden Zusammenführens von Komponenten zu einer Anwendung (https://de.wikipedia.org/wiki/Kontinuierliche_Integration). Das bedeutet in der klassischen Softwareentwicklung sprechen wir hier über einen Prozess, bei dem aus dem aktuellen Quellcode automatisch, also ohne weiteres Zutun der Entwickler, die Anwendung erstellt wird. Da aber in den wenigsten Fällen das reine Kompilieren einer Anwendung als Selbstzweck ausreicht, wird Continuous Integration typischerweise mit automatischen Tests der Anwendung gepaart. So erhält man nicht nur eine neue Anwendung, sondern (vorausgesetzt, die Entwicklung erfolgt testgetrieben) eine getestete Entwicklung, die im Idealfall von den Usern als Alpha-Version zum Testen neuer Features verwendet werden kann.

Dafür gibt es zwei wichtige Grundvoraussetzungen: einerseits, dass der aktuelle Quellcode der Anwendung an einer zentralen Stelle verwaltet wird, so dass sichergestellt werden kann, dass der CI-Prozess immer die aktuellsten Versionen aller Dateien verwendet. Andererseits müssen die Tests automatisiert und in relativ kurzer Zeit erfolgen können. Ein automatisierter Test, der mehrere Stunden läuft und den Checkin-Prozess damit verlangsamt, stünde ansonsten dem Arbeitsfluss stark im Wege.

Im Datenbank-Umfeld ist das Leben wie so oft nicht ganz so einfach. Das Testen von Datenbank-Anwendungen ist ein umfangreiches Thema, das sich nicht so einfach lösen lässt: um einen Cube beispielsweise aufzubereiten und fachlich zu testen, sind einerseits signifikante Datenmengen und andererseits teilweise auch größere Laufzeiten vonnöten. Hier ist ein automatisierter Test, der bestimmte Werte abfragt daher schwieriger zu implementieren. Auch im ETL-Bereich müssen Tests oftmals mit Massendaten erfolgen und sind daher Laufzeit- und Ressourcenintensiv.

CD, was ist das eigentlich?

Continuous Delivery (CD) ist die logische Konsequenz von Continuous Integration in einem agilen Arbeitsumfeld. Wenn ein Entwickler ein neues Feature entwickelt hat und den Source Code dafür in die Versionskontrolle eingecheckt hat, erfolgt per CI das Erstellen und Testen der Anwendung. Jetzt soll in einem agilen Prozess diese getestete Anwendung möglichst schnell dem Anwender zur Verfügung gestellt werden, damit er die Entwicklung testen und abnehmen kann. Wenn das Erstellen und Testen automatisiert erfolgt, ist es nur sinnvoll, die erfolgreich erstellte und getestete Anwendung automatisch an den Anwender auszurollen. Diesen Prozess bezeichnet man als Continuous Delivery.

Auch hier gibt es für Datenbank- und BI-Entwickler einige Besonderheiten. Das Ausrollen einer Änderung an einer Tabelle kann nämlich durchaus komplex sein (denken wir beispielsweise an das Hinzufügen eines „NOT NULL“-Feldes ohne Default-Wert zu einer gefüllten Tabelle). Anders als im reinen Software-Umfeld, wo solche Details im CD-Prozess meist keine größere Rolle spielen, handelt es sich hierbei für Datenbankentwickler um essenzielle Fragestellungen.

Warum CI/CD für Datenbanker?

Natürlich können sich Datenbank- oder BI-Entwickler nun auf den Standpunkt stellen, dass es angesichts der Probleme, die CI/CD-Prozesse in ihrem Umfeld mit sich bringen nicht sinnvoll ist, CI/CD anzuwenden. Dagegen spricht, dass auch und gerade im Datenbank-Umfeld eine testgetriebene Entwicklung und ein schnelles Ausrollen von Features einerseits von den Fachbereichen und Kunden verstärkt gefordert wird. Ebenso kann jeder Datenbank-Entwickler ruhiger schlafen, wenn er weiß, dass sein ETL-Paket in der Test-Umgebung erfolgreich gelaufen ist und damit das Risiko deutlich geringer ist, dass es Grund für einen fehlgeschlagenen Daily Load ist. Diese ruhigen Nächte können auch Skeptikern im Zweifel als Ansporn dienen, wenn Ihr versucht, in Projekten einen CI/CD-Prozess zu etablieren.