Mit Deployment-Pipelines die Qualität von Power BI-Berichten steigern

Microsoft Power BI ist das führende Tool für Datenanalyse und -visualisierung. Deployment Pipelines sind in der Softwareentwicklung Standard. Allerdings gibt es die Möglichkeit Deployment Pipelines nativ in Power BI zu nutzen erst seit kurzem und nur mit einem Premium-Abonnement. In diesem Blog-Beitrag zeigen wir Ihnen, wie Sie auch mit einer Power BI Pro-Lizenz Deployment-Pipelines für Ihre Reports erstellen und somit die Qualität Ihrer Berichte verbessern können.

Microsoft Power BI, ein Self-Service-Tool zur Datenanalyse und -visualisierung, erfreut sich immer größerer Beliebtheit. Weltweit nutzen über 250.000 Organisationen Power BI, um wertvolle Erkenntnisse aus ihren Datenbeständen zu gewinnen und bessere Entscheidungen zu treffen. Auch bei unseren Kund:innen, darunter Unternehmen in der Finanz- und Handelsbranche sowie NGO's, stößt Power BI auf immer größeres Interesse. Hier erfahren Sie, wie die Welthungerhilfe mithilfe der Azure Cloud und Power BI wertvolle Informationen gewinnt, um ihre weltweiten Projekte zu steuern. Unser Power BI-Seminar erfreut sich regelmäßig großer Nachfrage. Power BI überzeugt nicht nur Anwender:innen, sondern auch Gartner und wird in diesem Jahr erneut als stärkster Leader eingestuft.

Mit dem steigenden Einsatz von Power BI bei der Datenanalyse und Entscheidungsunterstützung steigen auch die Notwendigkeit und der Wunsch, die Qualität der Berichte und Dashboards sicherzustellen. Zum Beispiel müssen Kredit- und Finanzdienstleistungsinstitute Bankaufsichtliche Anforderungen an die IT (BAIT) erfüllen, u.a. die geregelte Funktionstrennung. Zudem stellt nicht selten der Datenschutz eine hohe Herausforderung im Entwicklungsprozess dar. All diese Anforderungen müssen berücksichtigt und bewerkstelligt werden bei gleichzeitig möglichst geringem Overhead im Bereitstellungsprozess. Hierbei stellt die Verwendung von Deployment-Pipelines eine sinnvolle Maßnahme dar.

Was sind Deployment-Pipelines?

Der Zweck einer Deployment-Pipeline besteht im Wesentlichen darin, eine Software mithilfe eines automatisierten Prozesses sicher in die Produktion zu bringen. Hierbei können beliebig viele Zwischenschritte (sog. Stages) stattfinden, um die Software in unterschiedlichen Umgebungen ausreichend zu testen und somit die Qualität der Software sicherzustellen. Zudem wird die Software in einem Repository versioniert, sodass im Falle eines auftretenden Fehlers schnell auf eine Vorgängerversion zurückgegriffen werden kann. Deployment-Pipelines sind in der Softwareentwicklung seit vielen Jahren State-of-the-Art.

Im Business Intelligence-Umfeld und der Entwicklung von Berichten und Dashboards mit Power BI sind Deployment-Pipelines nach unserer Erfahrung noch eher selten anzutreffen. Ein Grund dafür kann darin gesehen werden, dass Power BI erst seit kurzem Deployment-Pipelines nativ unterstützt. Dieses Feature stellt zwar einen ersten wichtigen Schritt in Richtung Qualitätssicherung und Effizienzsteigerung bei der Bereitstellung von Power BI-Berichten dar. Jedoch steht dieses Feature bislang nur für Power BI Premium-Abonnements zur Verfügung. Wir zeigen auf, wie Sie auch mit einer Power BI Pro-Lizenz Deployment-Pipelines einsetzen können.

Warum Deployment-Pipelines für Power BI Berichte?

Im Regelfall wird ein Power BI-Bericht mit dem kostenlosen Power BI Desktop entwickelt und nach Fertigstellung im Power BI-Dienst manuell veröffentlicht, sodass berechtigte Anwender den Bericht aufrufen können, um die bereitgestellten Daten zu analysieren. Dies ist zwar der schnellste und einfachste Weg, um einen Bericht einer bestimmten Anspruchsgruppe zur Verfügung zu stellen. Jedoch entstehen dabei einige Nachteile für die Qualität eines Berichts. Entweder findet gar keine Vorabprüfung z.B. durch eine:n zweite:n Entwickler:in und/oder fachliche:n Verantwortliche:n statt, sodass Fehler erst im Live-System festgestellt werden. Fehlerhafte Kennzahlen oder Fehler im Datenmodell können das Vertrauen der Anwender:innen in einen Bericht oder ein Dashboard nachhaltig beeinträchtigen und zu falschen Entscheidungen führen. Oder die Fehlerüberprüfung findet mithilfe eines manuellen Deployment-Prozesses statt.

Manuelles Deployment exemplarisch für einen Power BI-Bericht

Dies verringert zwar das Risiko eines fehlerhaften Berichts, bringt aber auch einige Nachteile mit sich. Einerseits ist der Workflow vergleichsweise umständlich und aufwendig. Oft genug ist es nicht erwünscht, dass Entwickler:innen zwecks Berichtdesign und Test Zugriff auf produktive Datenbestände erhalten. Das Verwenden der richtigen Datenbestände für Entwicklung, Test und Produktion ist mit manuellem Aufwand verbunden. Andererseits ist die Verbindlichkeit bei der Prüfung eher schwach ausgeprägt, d.h. es wird nicht unmittelbar festgehalten, ob eine Prüfung stattgefunden hat und wer sie durchgeführt hat. Für die Dokumentation müsste ein separates Verfahren parallel zum Prüfungsprozess durchgeführt werden.

Ein besseres Vorgehen ist, einen Power BI-Bericht nach der Entwicklung mit Power BI Desktop in ein Git-Repository hochzuladen, wodurch automatisch eine Deployment-Pipeline ausgelöst wird, die den Bericht zunächst in einer Testumgebung veröffentlicht. Ein:e vorher definierte:r Entwickler:in wird per E-Mail über den neu eingestellten Bericht informiert. Nach erfolgreichem Test wird die Änderung freigegeben. Dabei wird der Bericht automatisch in einer Abnahmeumgebung veröffentlicht und ein:e entsprechende:r Fachanwender:in wird automatisch per E-Mail über den eingestellten Bericht informiert. Erst nach erfolgreichem Test und Freigabe durch eine:n Fachverantwortliche:n wird der Bericht in der produktiven Umgebung veröffentlicht.

Verbesserter Lebenszyklus eines Power BI-Berichts

Diese Vorgehensweise hat gegenüber einem manuellen Vorgehen mehrere Vorteile. Zum einen wird ein Power BI-Bericht erst nach eingehender Prüfung und Test in die Produktion eingestellt. Auf diese Weise wird die Wahrscheinlichkeit für einen Fehler im Datenmodell oder einer Kennzahl reduziert und das Vertrauen in den Bericht gestärkt. Zum anderen findet die Bereitstellung des Berichts in den verschiedenen Umgebungen (d.h. Entwicklung, Test/Abnahme, Produktion) automatisiert statt und der Prozess inkl. Freigabe durch die entsprechenden Verantwortlichen wird zwecks späterer Nachvollziehbarkeit dokumentiert. Weiterhin sind Änderungen an Berichten nachvollziehbar und im Fehlerfall ist die Rückkehr zur vorherigen Berichtsversion möglich.

Deployment-Pipeline für Power BI Pro

Der verbesserte Lebenszyklus für Power BI Berichte kann mithilfe von Deployment-Pipelines auf Basis von Azure DevOps in Verbindung mit einem Git-Repository und der Power BI API abgebildet werden. Azure DevOps ist ein Service von Microsoft, mit dem Deployment-Pipelines in der Cloud erstellt werden können. Mit DevOps kann ein Workflow für ein Software-Artefakt (z.B. Power BI Bericht) definiert werden, in dem bestimmte Aufgaben in einer gewünschten Reihenfolge ausgeführt, definierte Anwender:innen über die Arbeitsschritte informiert und deren Freigabe eingeholt werden. Hierzu stehen Pipelines und sog. Release-Pipeline zur Verfügung. Eine Pipeline dient dazu, den Prozess für einen Bericht anzustoßen, der neu eingestellt oder geändert wurde. Dadurch wird eine Release-Pipeline ausgelöst, die daraufhin die jeweiligen Aufgaben (z.B. das Veröffentlichen eines Berichts in einer bestimmten Umgebung) ausführt. Das nachfolgende Bild veranschaulicht den Prozess vom Push einer Änderung im Git-Repository, über die Veröffentlichung in der Testumgebung bis zur Veröffentlichung in der Produktionsumgebung. Ein Bericht wird erst nach der Freigabe durch eine hierfür verantwortliche Person in der Produktionsumgebung veröffentlicht.

Schematische Deployment-Pipeline

In der Release-Pipeline für einen Power BI-Bericht werden ein Build- und ein Git-Artefakt benötigt. Das Build-Artefakt (1) stößt bei jeder Änderung im gewählten Branch des Git-Repositorys die Bearbeitung der Jobs in der Release-Pipeline an. Das Git-Artefakt (2) sorgt dafür, dass der aktuelle Bericht aus dem Git-Repository für das Deployment zur Verfügung steht. Innerhalb der Release-Pipeline werden die benötigten Stufen (z.B. Entwicklungs-, Abnahme-, Produktionsumgebung) festgelegt, in denen ein Bericht veröffentlicht werden soll. Für dieses Beispiel verwenden wir aus Gründen der Einfachheit die beiden Stufen "stage: dev&test" und "stage: production". Auf jeder Stufe dienen ein oder mehrere Jobs dazu, konkrete Aufgaben (d.h. Jobs bestehend aus Tasks) auszuführen. In diesem Beispiel wird auf jeder Stufe jeweils ein Job mit zwei Tasks ausgeführt.

Release Pipeline in Azure DevOps

Beide Tasks führen PowerShell-Skripte aus. Der erste Task installiert dabei zunächst die für den Zugriff auf die Power BI API benötigten PowerShell-Module.

Der zweite Task führt ein PowerShell-Skript aus, das alle API-Aufrufe enthält, um einen Bericht in einer bestimmten Stufe bereitzustellen. Die erforderlichen API-Aufrufe werden im nächsten Kapitel detailliert beschrieben.

Analog zu den Stufen haben wir in der Power BI App die beiden Arbeitsbereiche "Stage: Dev&Test" und "Stage: Production" angelegt. Für Entwicklung und Test eines Power BI-Berichts dient der Arbeitsbereich "Stage: Dev&Test". Der Arbeitsbereich "Stage: Production" ist die Zielstufe für die produktiven Power BI Reports. Jedem Arbeitsbereich können entsprechende Zugriffsberechtigungen, z.B. auf Basis von Azure Active Directory Gruppen zugeordnet werden. Somit wird sichergestellt, dass nur die berechtigten Mitarbeiter:innen Zugriff auf die Berichte in den jeweiligen Arbeitsbereichen erhalten.

Um in jeder Stufe der Release-Pipeline den richtigen Arbeitsbereich in Power BI anzusprechen, haben wir jeder Stufe eine entsprechende Variablengruppe zugeordnet. In jeder Variablengruppe werden die benötigten Informationen zur Authentifizierung und für den zu verwendenden Power BI-Arbeitsbereich hinterlegt. Dadurch wird sichergestellt, dass in jeder Stufe die richtigen Informationen zur Verfügung stehen.

Variablengruppen für verschiedene Umgebungen

Vor und nach der Bearbeitung der Jobs auf einer Stufe können Bedingungen (sog. Pre- & Post-Deployment Conditions) festgelegt werden. In diesem Beispiel verwenden wir eine Post-Deployment-Condition (3), um einen Power BI-Bericht erst nach erfolgreicher Freigabe durch einen verantwortlichen Mitarbeiter in der "Stage Production" bereitzustellen. Somit wird sichergestellt, dass nur geprüfte und freigegebene Berichte bereitgestellt werden. Die entsprechenden Mitarbeiter:innen werden per E-Mail benachrichtigt, sobald eine Post-Deployment-Condition erreicht wird.

Power BI API-Aufrufe für das Deployment

In diesem Szenario verwenden wir einen Power BI-Bericht mit einer Live Connection zu einem Dataset, das vom Power BI-Dienst bereitgestellt wird. Der Report enthält alle Informationen für Darstellung und Filterung der Daten. Das Dataset enthält die Informationen über die Verbindung zu den Datenquellen, das Datenmodell und stellt die Daten für den Report bereit. Die Trennung der Verantwortlichkeiten hat mehrere Vorteile. Zum einen kann ein Dataset von mehreren Reports wiederverwendet werden. Ein Datenmodell muss nur einmal erstellt werden und mehrere verschiedene Power BI Reports können darauf zugreifen. Änderungen im Dataset sind dann automatisch in allen abhängigen Reports verfügbar. Zum anderen können Datenmodell und Report unabhängig voneinander entwickelt werden.

Für das Deployment bedeutet dies, dass mindestens zwei Pipelines benötigt werden. Eine Pipeline für das Dataset. Und jeweils eine Pipeline für jeden Report. Nachfolgend werden die PowerShell-Tasks der jeweiligen Stufe detailliert beschrieben.

Dataset Task in Stage Dev&Test

Dieser Task besteht aus zwei Anweisungen. Die erste Anweisung Connect-PowerBIServiceAccount dient dazu, den Service-Principal (d.h. technischer Nutzer) in der Power BI API zu authentifizieren. Die zweite Anweisung New-PowerBIReport veröffentlicht das Dataset im Arbeitsbereich "Stage Dev&Test". Bei der Veröffentlichung wird als ConflictAction CreateOrOverwrite verwendet, sodass mit nur einer Anweisung entweder ein neuer Bericht angelegt oder ein bereits existierender Bericht ersetzt wird. Die relevanten Informationen für API-Aufrufen (z.B. Azure-Mandant, Passwort, Arbeitsbereich) werden aus der Variablengruppe (dev&test) abgerufen, die der Stufe zugeordnet ist.

Dataset Task in Stage Production

Im Job für das Deployment eines Datasets in der Produktionsumgebung werden zusätzliche API-Aufrufe benötigt. Nachdem das Dataset veröffentlicht wurde, muss zunächst sichergestellt werden, dass der Service-Principal die Erlaubnis für die Bearbeitung erhält. Dies geschieht mit dem Aufruf TakeOver.

Da das Dataset mit einer Datenbank verbunden ist und die Verbindung zurzeit noch auf die Testdatenbank zeigt, müssen die Parameter auf die Produktionsdatenbank geändert werden. Dies wird mit zwei API-Aufrufen erreicht. Im ersten Aufruf UpdateParameters wird der richtige Parameter für Datenbankschema gesetzt. Im zweiten Aufruf UpdateDatasources werden die Verbindungsdetails für die Produktionsdatenbank gesetzt. Da sich die Datenbank in diesem Beispiel On Premise bzw. in einem privaten Netzwerk befindet, wird der Zugriff von Power BI auf die Datenbank mithilfe des sog. Power BI Gateways geregelt. Daher muss bei der Aktualisierung der Verbindungsdetails UpdateDatasources zusätzlich auch die Id des Gateways übergeben werden.

Bei der Aktualisierung der Verbindungsdetails geht die Zuordnung zum Gateway verloren. Diese Zuordnung wird mit dem API-Aufruf BindToGateway wiederhergestellt. Im letzten Schritt werden die Daten mit dem Kommando Refreshes aktualisiert, damit das Dataset die produktiven Daten bereitstellt.

Report Task in Stage Dev&Test

Der Task für den Report besteht analog zu dem Task für das Dataset aus den beiden API-Aufrufen für Authentifizierung und Veröffentlichung des Berichts.

Report Task in Stage Production

Für das Deployment des Reports in der Produktionsumgebung muss nach der Veröffentlichung die Verbindung zum Dataset der Produktionsumgebung hergestellt werden. Dies wird mit dem API-Aufruf Rebind erreicht.

Unsere Empfehlung für Deployment-Pipelines

In der Software-Entwicklung erlauben Deployment-Pipelines die automatisierte Bereitstellung von Softwareänderungen in Test-, Abnahme- und Produktionsumgebungen. Deployment-Pipelines unterstützen die Qualitätssicherung eines Softwareprodukts und sorgen für eine höhere Effizienz bei dessen Auslieferung. Sie sind im Bereich der Software-Entwicklung nicht mehr wegzudenken. Bei der Entwicklung von Power BI-Berichten sind automatisierte Deployment-Pipelines bislang eher selten anzutreffen. In diesem Beitrag haben wir gezeigt, wie mithilfe der Power BI API und Azure DevOps Deployment-Pipelines für Power BI abgebildet werden können.

Sobald die Nutzung von Power BI über eine Proof-of-Concept-Phase hinausgeht, empfehlen wir die Verwendung von automatisierten Deployment-Pipelines. Deployment-Pipelines bieten eine Reihe von Vorteilen. Entwickler:innen und Fachverantwortliche müssen sich bei der Verwendung getrennter Umgebungen nicht manuell um das Setzen der richtigen Verbindungsparameter kümmern. Falsche Verbindungen zu Datasets oder Datenbanken werden durch standardisierte PowerShell-Skripte verhindert. Die richtige Konfiguration findet durch einen technischen Nutzer statt. Entwickler:innen benötigen somit keine Berechtigungen für gesicherte Umgebungen, um die richtigen Verbindungen zu setzen. Regulatorische Anforderungen, wie eine geregelte Funktionstrennung, werden eingehalten. Nach dem initialen Aufwand für die Einrichtung einer Pipeline wird die Qualitätssicherung durch ein teilautomatisiertes Verfahren unterstützt. Dadurch entfällt der manuelle Abstimmbedarf zwischen Entwickler:innen und Fachverantwortliche beim Verschieben einer Änderung bis in die Produktion. Die Benachrichtigung der Prozessbeteiligten wird durch die DevOps-Pipelines per E-Mail sichergestellt.

Als Herausforderung bei der Erstellung der Deployment-Pipelines für Power BI-Berichte stellte sich vor allem die vollständige Einrichtung des Service-Principals (d.h. technischer Nutzer) dar. Nach der Einrichtung der App-Registrierung in Azure und der Erteilung der Berechtigung in Power BI mussten noch die Berechtigungen für den Zugriff auf die Power BI API in Azure gesetzt werden. Bei Verwendung des Power BI Gateways ist zudem noch der Service-Principal als Administrator des Gateways einzurichten. Sobald diese Hürden überwunden sind, funktionieren die benötigten API-Aufrufe problemlos.

Aus unserer Sicht wäre es wünschenswert, wenn die Änderungen an einem Bericht unmittelbar durch einen Vorher-/Nachher-Vergleich anhand des Programmcodes sichtbar wären. Diese Möglichkeit fehlt aktuell noch sowohl im manuellen als auch im automatischen Deployment-Prozess. Wir behalten ein Highlighting von Berichtsänderungen im Blick und halten Sie über Fortschritte in diesem Bereich auf unserem Blog auf dem Laufenden.

Austausch zum Thema Deployment-Pipelines für Power BI-Berichte

Wie stellen Sie die Qualität Ihrer Power BI-Berichte und Dashboards sicher? Verwenden Sie bereits Deployment-Pipelines für Power BI? Haben Sie Fragen zur Einrichtung von Deployment-Pipelines? Sprechen Sie uns gerne an und/oder connecten Sie sich mit mir bei XING.