Power BI und Azure DevOps: Gemeinsame Berichtsentwicklung mit Softwareentwicklungsprinzipien

DevOps, CI/CD, die Verwendung von Git-Repos - all das gehört in der klassischen Software-Entwicklung seit Jahren zum Standard. In der Berichtsentwicklung ist dies auch heute noch eher die Ausnahme. Deswegen wollen wir in diesem Blogbeitrag vorführen, wie man mit Buildpipelines verlässliche und konsistente Power BI-Berichte im Team entwickeln kann, die zudem definierten Regeln folgen, z.B. für DAX-Codierungen, Sortierungen oder Formatierungen.

1. Konsistenz: CI/CD-Pipelines fördern eine einheitliche Vorgehensweise bei der Berichtserstellung. Durch automatisierte Tests und Validierungen wird sichergestellt, dass alle Berichte den festgelegten Standards entsprechen.
2. Schnelligkeit und Effizienz: Automatisierte Deployments reduzieren manuelle Aufgaben und beschleunigen den gesamten Prozess. Änderungen an Berichten können schneller implementiert und bereitgestellt werden.
3. Fehlerreduktion: Automatisierte Tests helfen, potenzielle Fehler frühzeitig zu identifizieren, bevor Berichte in die Produktion gehen. Dies minimiert das Risiko von fehlerhaften Datenvisualisierungen oder -analysen.
4. Nachvollziehbarkeit: Mit CI/CD-Pipelines können alle Änderungen an Berichten und Datasets dokumentiert werden. Dies schafft Transparenz und ermöglicht eine einfache Rückverfolgbarkeit bei Bedarf.
5. Teamzusammenarbeit: CI/CD-Methoden fördern die Zusammenarbeit im Team, indem sie eine strukturierte Umgebung schaffen, in der mehrere Benutzer gleichzeitig an Berichten arbeiten können, ohne Konflikte zu verursachen.

Im weiteren Verlauf werden wir einmal das Vorgehen beim Erstellen einer solchen Pipeline aufzeigen. Die Vorteile einer Versionskontrolle (DataOps und Data Version Control (DVC) - rheindata GmbH) oder speziell bei Power-BI Berichten (Power BI Github Data Pipelines - rheindata GmbH) haben wir bereits in weiteren Blogbeiträgen auf unserer Seite veröffentlicht und werden hier daher nicht weiter thematisiert.

In diesem Beitrag gehen wir die notwendigen Schritte zur Erstellung einer Buildpipeline durch. Im unteren Schaubild wird einmal der Aufbau einer solchen Entwicklungspipeline (grün) und die jeweiligen Schritte grob skizziert.

Quelle: Azure DevOps Buildpipeline-Integration in Power BI Desktop-Projekte - Power BI | Microsoft Learn

Nutzer 1 entwickelt mit Power BI Desktop (linke Seite)

1. Erstellt einen neuen Branch von main in VS Code (feature/datasetchange).
2. Nimmt Änderungen am semantischen Modell in Power BI Desktop vor.
3. Committet die Änderungen in den Remote-Repository-Branch über VS Code.
4. Erstellt einen Pull Request zum main-Branch in Azure DevOps.

Nutzer 2 arbeitet gleichzeitig in einem anderen Fabric-Arbeitsbereich (rechte Seite)

1. Erstellt einen neuen Branch von main in Fabric Git (feature/reportchange).
2. Nimmt Änderungen am Bericht direkt im Fabric-Arbeitsbereich (Dev) vor.
3. Committet die Änderungen in den Remote-Repository-Branch über Fabric Git.
4. Erstellt einen Pull Request zum main-Branch in Azure DevOps.

Nach dem Verbinden des Arbeitsbereiches mit unserem Azure DevOps Projekt (CI/CD-demo) werden die Artefakte nun synchronisiert (Status: Syncing > Synced).

Nach der erfolgreichen Synchronisierung erscheinen dann die einzelnen Artefakte auch in unserem Repo in Azure DevOps.

1. test-powerbi-devops-Report
2. test-powerbi-devops-Semanticmodell

Wenn wir einen weiteren Bericht im Arbeitsbereich hinzufügen, wird auch dieser als weiteres Ordner-Paar aufgelistet (hier am Beispielbericht „test“ verdeutlicht).

Hier treffen wir die Auswahl, wo sich der Code für unsere Pipeline befindet. Da wir unsere Entwicklungen in Azure Repos erstellt und gesichert haben, können wir die erste Variante ‚Azure Repos Git‘ auswählen.

Anschließend wählen wir noch das korrekte Repository aus (in unserem Fall (CI/CD-Demo) und nutzen die Vorlage für eine Startpipeline.

Hier wählen die Vorlage für eine Starter-YAML Datei (Starter Pipeline) aus.

Für unsere YAML File müssen wir nun eine kleine Änderung vornehmen. Dazu kopieren wir uns den Code für unsere Power-BI Entwicklungs Pipeline hier und fügen diesen in unsere Datei ein.

Anschließend klicken wir auf „Save & Run“, um die Pipeline erstmals auszuführen.

Nun sehen wir, dass mit der Änderung an unserer YAML File nun zwei Jobs ausgeführt werden:

1. Build_Datasets
2. Build_Reports

Mit dieser kleinen Änderung können wir uns die gesamten Vorteile einer Pipeline zu Nutze machen. Mit Hilfe von zwei Open-Source Tools (Tabular-Editor und PBI Inspector) können wir nun Regeln erstellen, die wir vor den Änderungen bei Berichten und Sematikmodellen prüfen wollen. Diese Regeln können wir zusätzlich auch nach Wichtigkeiten kategorisieren, d.h. Warnungen werden nicht dazu führen, dass eine Pipeline nicht erfolgreich durchläuft, bei Fehlern wird hingegen abgebrochen und wir müssen diese in unserem Bericht erst bereinigen. Das bedeutet wir können einmal Regeln für unseren Bericht auf visueller Basis festlegen, wie z.B.

1. Reportseiten sollen nicht mehr als 10 Visuals besitzen. (Warnung)
2. Es dürfen nur festgelegte und vorab definierte Farben verwendet werden. (Fehler)
3. Berichte dürfen nur eine bestimmte Seitengröße haben. (Fehler)

Des Weiteren können wir aber auch für unsere Semantikmodelle wichtige Best-Practice Regeln definieren, die bei Fehlern dazu führen, dass unsere Berichte erst gar nicht in die Arbeitsbereiche hochgeladen werden und so schon vorab Fehlerquelle zu identifizieren und zu bereinigen, sodass eine einheitliche Berichtsentwicklung auch auf Datenebene gewährleistet ist.

1. Spalten dürfen nicht aufsummiert werden.
2. Nummern sollten mit Tausender-Trennzeichen formatiert werden.
3. Monate als Text (April, August, etc. ) sollten nach den Monatsnummern sortiert werden.
4. Für Divisionen sollte immer die DIVIDE Funktion genutzt werden.

Nachdem unsere Pipeline gelaufen ist, bekommen wir nun eine gesammelte Übersicht der Warnungen und Fehlermeldungen:

Hie sehen wir drei Beispiele, die dazu geführt haben, dass wir eine Fehlermeldung bekommen haben:

1. Unsere Spalte ‚Sales‘ beginnt mit einem Leerzeichen.
2. Unser Measure ‚DIVIDE CALCULATION‘ hat keine korrekte Formatdefinition.
3. Numerische Spalten sollten nicht summiert werden.

Sobald die Pipeline eingerichtet und funktionsfähig ist, sollten außerdem Branch-Richtlinien für den main-Branch aktiviert werden. Dieser Schritt stellt sicher, dass keine direkten Commits in den main-Branch erfolgen können. Stattdessen ist immer ein "Pull Request" erforderlich, um Änderungen wieder in den main-Branch zu mergen.

Darüber hinaus kann die Pipeline so konfiguriert werden, dass sie bei jedem Pull Request nun automatisch ausgeführt wird. Diese Vorgehensweise trägt zur Qualitätssicherung bei, da sie sicherstellt, dass alle Änderungen überprüft und validiert werden, bevor sie in den Hauptzweig integriert werden. So bleibt der main-Branch stabil und zuverlässig ohne vorher definierte Fehler zu übernehmen.

Wenn wir nun direkt auf den main-branch eine Änderung durchführen (z.B Löschen von Reports) wollen würden, bekommen wir eine Fehlermeldung, dass dies aufgrund unserer definierten Regeln nicht zulässig ist.

Für Änderungen oder den Einbau neuer Features müssen wir somit einen neuen Branch erstellen.

Der neue Feature-Branch (feature/deletereports) wird uns nun auch im Repository angezeigt:

Nun müssen wir hier einen Pull-Request erstellen um die Änderungen auf unseren Main Branch zu mergen. Wir vergeben zusätzlich noch einen Titel (und Beschreibung), um nachvollziehbar zu dokumentieren, was für Änderungen hier durchgeführt wurden.

Nun wird unsere Pipeline automatisch ausgeführt und die Änderungen werden vom featurebranch in unseren main branch gemerged . Die Änderungen wurden zusätzlich auch in unseren Arbeitsbereich im Power-BI Service übertragen.