Power BI Project (PBIP) und Azure DevOps Buildpipelines für kontinuierliche Integration

Durch die Kombination der Fabric Git-Integration mit Azure DevOps können Sie einen Arbeitsbereich mit einer Verzweigung in einem Azure DevOps-Repository verbinden und automatisch zwischen ihnen synchronisieren.

Durch die Integration des PBIP-Formats in Azure DevOps können Sie Azure-Pipelines verwenden, um Pipelines für Continuous Integration und Continuous Delivery (CI/CD) zu automatisieren. Diese Pipelines verarbeiten die PBIP-Metadatendateien und wenden eine Reihe von Qualitätsprüfungen auf Ihre Entwicklung an, bevor sie im Produktionssystem bereitgestellt werden.

In diesem Artikel konzentrieren wir uns auf die kontinuierliche Integration und beschreiben, wie Sie eine Azure DevOps-Buildpipeline erstellen, die bewährte Methoden für alle semantischen Modelle und Berichte in einem Fabric-Arbeitsbereich garantiert. Durch die Implementierung automatisierter Qualitätstests können Sie häufige Fehler vermeiden und die Teameffizienz verbessern. Mit diesem Ansatz wird beispielsweise sichergestellt, dass neue Teammitglieder den etablierten Standards für semantische Modelle und Berichtsentwicklung entsprechen.

Erfahren Sie mehr über PBIP und Fabric Git Integration in der Projektübersicht und Fabric Git-Integrationsübersicht.

Das folgende Diagramm veranschaulicht das End-to-End-Szenario mit zwei Entwicklungsworkflows, die die Azure DevOps-Buildpipeline auslösen, um die Entwicklungsqualität zu überprüfen. Das Build führt die folgenden Aktionen aus:

1. Benutzer 1 entwickelt mit Power BI Desktop.

   1. Erstellen einer Verzweigung aus Main mithilfe von VS Code (Feature/Datasetchange)
   2. Vornehmen von Änderungen am semantischen Modell mithilfe von Power BI Desktop
   3. Übernehmen von Änderungen an Remoterepository-Branch mithilfe von VS Code
   4. Erstellen einer Pull Request für Main Branch mithilfe von Azure DevOps

2. Gleichzeitig entwickelt Benutzer 2 mit einem anderen Fabric-Arbeitsbereich.

   1. Erstellen einer Verzweigung aus Main mithilfe von Fabric Git (Feature/Reportchange)
   2. Vornehmen von Berichtsänderungen im Fabric-Arbeitsbereich
   3. Übernehmen von Änderungen an Remoterepository-Branch mithilfe von Fabric Git
   4. Erstellen einer Pull Request für Main Branch mithilfe von Azure DevOps

3. Der Teamleiter überprüft die Pull Requests und synchronisiert die Änderungen mit Fabric Git mit dem Teamarbeitsbereich.

4. Der Pull Request löst die Azure DevOps Build-Pipeline aus, um das semantische Modell zu prüfen und die Entwicklungsqualität zu melden.

Hinweis

In diesem Beispiel verwendet die Buildpipeline zwei Open-Source-Communitytools, mit denen ein Entwickler Best Practice-Regeln (anpassbar) auf die Metadaten von semantischen Modellen und Berichten in einem Power BI-Projektordner anwenden kann:

• Tabular Editor und Best Practices-Regeln
• PBI Inspector

Ein Ansatz, der dem Beispiel in diesem Artikel ähnelt, würde sich auf andere Communitytools beziehen. Dieser Artikel befasst sich weder mit den Besonderheiten der zuvor erwähnten Community-Tools noch mit der Erstellung und Bearbeitung von Regeln. Ausführliche Informationen zu diesen Themen finden Sie unter den bereitgestellten Links. Der Schwerpunkt dieses Artikels liegt auf dem Prozess der Einrichtung eines Quality Gate zwischen der Versionskontrolle und Fabric Workspace. Bitte beachten Sie, dass die genannten Communitytools von Drittanbietern entwickelt wurden und dass Microsoft weder Support noch Dokumentation für sie anbietet.

Schritt 1 – Verbinden des Fabric-Arbeitsbereichs mit Azure DevOps

Verbinden Ihres Fabric-Arbeitsbereichs mit Azure DevOps:

Wenn die Fabric Git-Integration den Export Ihrer Arbeitsbereichselemente abgeschlossen hat, enthält Ihre Azure DevOps-Verzweigung einen Ordner für jedes Element in Ihrem Arbeitsbereich:

Schritt 2: Erstellen und Ausführen einer Azure DevOps-Buildpipeline

So erstellen Sie eine neue Buildpipeline:

1. Wählen Sie auf der Registerkarte Pipelines im linken Navigationsmenü Pipeline erstellen aus:

   

2. Wählen Sie Azure Repos Git aus, und wählen Sie das erste Repository aus (dasselbe Repository, das mit dem Fabric-Arbeitsbereich verbunden ist):

   

   

3. Wählen Sie Starterpipeline aus.

   

   Der folgende YAML-Code wird im Editor angezeigt:

   

4. Kopieren Sie den YAML-Code aus der Power BI-Entwicklermoduspipeline, und fügen Sie ihn in die von Ihnen erstellte Pipeline ein:

   

   

5. Wählen Sie Speichern und ausführen aus, um die neue Pipeline in das Repository zu übernehmen.

   

   

Azure DevOps führt die Pipeline aus und startet zwei Buildaufträge parallel:

• Build_Datasets
  • Lädt Tabular Editor-Binärdateien herunter.
  • Laden Sie die Standardregeln für Best Practice Analyzer herunter. Um die Regeln anzupassen, fügen Sie dem Stammverzeichnis des Repositorys eine Rules-Dataset.json hinzu.
  • Durchlaufen Sie alle Elementordner von semantischen Modellen, und führen Sie BPA-Regeln des Tabular Editors aus.
• Build_Reports
  • Laden Sie PBI Inspector-Binärdateien herunter.
  • Laden Sie PBI Inspector-Standardregeln herunter. Um die Regeln anzupassen, fügen Sie dem Stammverzeichnis des Repositorys eine Rules-Report.json hinzu.
  • Durchlaufen Sie alle Berichtselementordner, und führen Sie Power BI Inspector-Regeln aus.

Nach Abschluss erstellt Azure DevOps einen Bericht aller Warnungen und aufgetretenen Fehler:

Wählen Sie den Link aus, um eine detailliertere Ansicht der beiden Buildaufträge zu öffnen:

Wenn der Bericht oder das semantische Modell eine Regel mit einem höheren Schweregrad nicht erfüllt, schlägt der Build fehl, und der Fehler wird hervorgehoben:

Schritt 3: Definieren von Branch-Richtlinien

Sobald die Pipeline ausgeführt wird, aktivieren Sie Branch-Richtlinien für die Main-Branch. Dieser Schritt stellt sicher, dass keine Commits direkt in Standard erfolgen können. Eine Pull Request ist immer erforderlich, um Änderungen wieder in Main zusammenzuführen, und Sie können die Buildpipeline so konfigurieren, dass sie mit jeder Pull Request ausgeführt wird.

1. Wählen Sie Branches>Main-Branch>Branch-Richtlinien aus:

   

2. Konfigurieren Sie die erstellte Pipeline als Buildrichtlinie für die Verzweigung:

   

   

Schritt 4: Pull Request erstellen

Wenn Sie zu Ihrem Fabric Workspace zurückkehren, eine Änderung an einem der Berichte oder semantischen Modelle vornehmen und versuchen, die Änderung zu bestätigen, erhalten Sie die folgende Fehlermeldung:

Sie können nur Änderungen an der Main-Branch über eine Pull Request vornehmen. So erstellen Sie eine Pull Request, um eine neue Verzweigung zu erstellen, um die Änderungen vorzunehmen:

Erstellen Sie eine Verzweigung direkt aus dem Fabric-Arbeitsbereich:

1. Wählen Sie im Bereich „Quellcodeverwaltung“ die Option Neue Verzweigung auschecken aus, und geben Sie einen Namen für die Verzweigung an.

   

   

   Alternativ können Sie in einem separaten, isolierten Arbeitsbereich oder in Power BI Desktop entwickeln. Weitere Informationen finden Sie unter Entwickeln mit einem anderen Arbeitsbereich.

2. Committen Sie Ihre Änderungen an dieser neuen Verzweigung.

   

3. Erstellen Sie nach dem Commit eine Pull Request in der Main-Branch aus dem Azure DevOps-Portal.

   

   

Der Pull Request-Workflow ermöglicht es Ihnen nicht nur, die Änderungen zu überprüfen, sondern löst auch automatisch die Buildpipeline aus.

Wenn in einem der Regeln ein Buildfehler mit hohem Schweregrad auftritt, können Sie die Pull Request nicht abschließen und die Änderungen wieder in die Main-Branch zusammenführen.

Weitere Informationen zu PBIP und Fabric Git Integration finden Sie im Blogbeitrag.