Business Intelligence entwickelt sich seit Mitte der 1990er Jahre stetig vorwärts. So ist es nicht verwunderlich wenn etablierte Konzepte aus der Informatik auch in das BI-Umfeld übernommen werden. Spätestens seit der Buchveröffentlichung von Kent Beck unter dem Titel Extreme Programming ist der Begriff Continuous Integration sehr populär geworden. Die damit verbundenen Konzepte sind in der aktuellen Softwareentwicklung nicht mehr wegzudenken. Wie lässt sich CI und BI miteinander in einklang bringen?
Unterschiede zwischen klassischen Software- und BI-Systemen
Die Entwicklung klassischer Softwaresysteme hat seit mehreren Jahrzehnten ein starkes und etablierters Fundament . Die Entwickler solcher Systeme können auf Programmiersprachen, Bibliotheken, Literatur und etablierten Werkzeugen zurückgreifen. Die Open Source Bewegung mag diesen Effekt noch verstärkt haben.
BI-Systeme hingegen sind technisch interdisziplinär, zudem aber auch sehr spezialisiert und häufig proprietär: spezielle Algorithmen im Online Analytical Processing (OLAP) oder Data Mining, Architektur multidimensionaller Datenbanken, spezialisierte Design-Werkzeuge zur Modellierung von Extract-Transform-Load-Prozessen (ETL), Big Data, MPP Datenbanken usw.
Interdisziplinarität und hohe Spezialisierung bedeutet immer Fachexpertise und somit “kleinerer” Expertenkreis, im Vergleich zur der Zahl von Softwareentwicklern. Dass die Systeme zumeist proprietär sind, beschränkt natürlich die Entwicklung von Werkzeugen, die in der klassischen Softwareentwicklung zum Standardrepertoire gehören.
Diese Eigenschaften sind kurz gesagt die Kernursache dafür, dass sich übliche Prozesse, dazu gehört auch Continuous Integration, nur schwer etablieren.
Contiuous Integration mit dem Team Foundation Server
Die Liste der Buzzwords ist lang: TFS, ALM, ALM-Ranger, Branching Plan, automatisiertes Testen, Continuous Delivery, Deployment Pipeline, Extreme Programming und und und….
Der TFS verspricht viel, wer allerdings denkt alle Herausforderungen seien damit auf einen Schlag erledigt wird enttäuscht sein. CI muss Brücken schlagen zwischen Systemen, die dafür konzipiert sind Teilaufgaben perfekt aber in Eigenregie zu erledigen. Erst die Kombination einer vielzahl von Systemen ergibt in Summe am Ende CI. Funktioniert nur ein Teilsystem nicht, oder schlecht ist CI in gänze gefährdet.
Ein oft vernachlässigter Aspekt ist, dass nicht nur die Systeme perfekt funktionieren müssen, CI muss auch vom Team “gelebt” werden. Ist das nicht der Fall wird CI ebenfall nicht funktionieren.
Versionskontrolle
Alle Bestandteile die benötigt werden um eine BI-Lösung zu erstellen müssen unter Versionkontrolle gestellt werden. Dabei stellt sich oft die Herausforderung mit Dateien umzugehen die nicht Vereint (Merge) werden können. Gleichzeitig wächst bei größeren Teams der Anspruch parallel Arbeiten zu können. Kommt eine komplizierte Release-Planung hinzu bei der bestimmte Features zu verschiedenen Zeitpunkten ausgeliefert werden müssen wird es erst recht kompliziert. In der Praxis hat sich hier ein ausgeklügelter Branching Plan als praktikabel erwiesen; wer hier weiter Forschen möchte sollte sich unbedingt die Visual Studio Team Foundation Server Branching and Merging Guide der ALM Ranger durchlesen.
Automatisierung des Builds
Bei der automatisierung des Builds gibt es zwei verschiedene Definitionen in der Literatur und im Web. Die meiner Meinung nach ursprüngliche Idee bestand darin alle Bestandteile der Versionskontrolle so zu Übersetzen, dass diese quasi als direktes Installationsmedium für eine Installation verwendet werden kann. Neuerdings findet man noch den Zusatz, dass auch automatisch eine Integrationsumgebung bespielt wird. Ich sehe beide beide Aufgaben aber getrennt und letztere nicht im Rahmen der Buildautomatisierung. Wer schwere Aufgaben in kleine einfachere Teilaufgaben zerlegen möchte wird ohnehin nicht um eine Trennung herumkommen.
Klassisch kann der TFS-Build Visual-Studio-Solution oder MSBuild Dateien direkt übersetzen. Dabei werden die Solutions mit einer generierten MSBuild-Datei (eine Art Wrapper) übersetzt. Leider können die BI-Projekte (stand heute) nicht direkt mit MSBuild übersetzt werden daher kommt es z.B. zu folgendem Fehler:
MSB4078: The project file “Reports\Reports.rptproj” is not supported by MSBuild and cannot be built.
Diese Problem kann umgangen werden in dem man einen eigenen MSBuild-Wrapper für seine BI-Projekte erstellt. Dies macht auch noch aus einem ganz anderen Aspekt sinn: Die meisten BI-Projekte sind alleine nicht lauffähig; meint Reports benötigen Cubes oder Datenbanken, Cubes brauchen ein Datawarehouse und damit Daten vom Vorsystem in das Datawarehouse kommem wird ETL bzw. SSIS benötigt. Der Build muss also das Ziel haben alle BI-Fragmente in einem installierbaren Format zu liefern.
Hat man die Versionskontrolle eingeführt und einen Build wie oben berschrieben realisiert, kann mit dem TFS ein rudimentärers CI-System aufgebaut werden.
Automatisierung des Deployments
Ein automatisiertes Deployment setzt auf den Ergebnissen des Builds davor auf. Dieser Build sollte uns nun in einem speziellen Repository alle für das Deployment benötigten BI-Fragmente zur Verfügung stellen. Darüber hinaus sollte solch ein Deployment auch unabhängig von der Zielumgebung sein, also in einem hohen Maße konfigurier bar.
Aufgrund der Nähe zu den anderen Microsoft-Produkten und der benötigten flexibilität habe ich solche Deployments immer in PowerShell implementiert. Im absoluten Notfall kann hier auch auf .Net-Bibliotheken zurückgegriffen werden. Natürlich kann ein automatisiertes Deployment in jeder beliebigen Scriptsprache implementiert werden.
Fazit
Ein Blogbeitrag kann Continuous Integration im BI-Umfeld nicht vollumpfänglich erfassen. Es gibt leider keinen De-facto standard im Microsoft BI-Bereich. Ich hoffe dieser Beitrag hat ein Verständnis für die dahinterliegende Komplexität geschaffen. Weitere Details werde ich versuchen in weiteren Beiträgen zu erklären.