Freigeben über


Power BI-Projekt (PBIP) und Azure DevOps-Buildpipelines für Prüfungen

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-Pipeline erstellen, die bewährte Methoden für alle Semantikmodelle 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-Pipeline auslösen, um die Entwicklungsqualität zu überprüfen. Die Pipeline führt die folgenden Aktionen aus:

Diagramm: Workflow der DevOps-Pipeline

  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-Pipeline aus, um das Semantikmodell und die Qualität der Berichtsentwicklung zu prüfen.

Hinweis

In diesem Beispiel verwendet die Pipeline zwei Open-Source-Communitytools, mit denen ein Entwickler (anpassbare) Regeln für bewährte Methoden auf die Metadaten von Semantikmodellen und Berichten in einem Power BI-Projektordner anwenden kann:

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:

Screenshot: Git-Verbindung zu 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:

Screenshot: Azure DevOps-Branch mit Ordnern für verschiedene Arbeitsbereichselemente

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

So erstellen Sie eine neue Pipeline

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

    Screenshot: Erstellung einer Pipeline

  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):

    Screenshot: Azure-Repository-Git, das als Codequelle für die Pipeline ausgewählt wurde

    Screenshot: Ausgewähltes Demo-ADObuild-Repository

  3. Wählen Sie Starterpipeline aus.

    Screenshot: Ausgewähltes Starterpipelinesymbol

    Der folgende YAML-Code wird im Editor angezeigt:

    Screenshot: YAML-Standardcode

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

    Screenshot: Hinzuzufügender YAML-Code

    Screenshot: Zweiter Teil des YAML-Codes

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

    Screenshot: Überprüfung des YAML-Codes

    Screenshot: Auswahl „Speichern und ausführen“

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

Screenshot: Azure DevOps mit ausgeführter Pipeline

  • 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:

Screenshot: Fehlerbericht

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

Screenshot: Schaltfläche zum Anzeigen des Protokolls

Screenshot: Erweitertes Fehlerprotokoll

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:

Screenshot: Hervorgehobene Fehler

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. Ein „Pull Request“ ist immer erforderlich, um Änderungen wieder in Main zusammenzuführen. Sie können die Pipeline so konfigurieren, dass sie mit jedem Pull Request ausgeführt wird.

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

    Screenshot: Branchrichtlinien

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

    Screenshot: Benutzeroberfläche für die Buildrichtlinie

    Screenshot: Zweiter Teil der Benutzeroberfläche für die Buildrichtlinie

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:

Screenshot: Fehler, dass Änderungen nicht committet werden können

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.

    Screenshot: Bildschirm der Quellcodeverwaltung zum Auschecken eines neuen Branchs

    Screenshot: Auschecken eines neuen Branchs

    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.

    Screenshot: Commitänderungen am Branch

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

    Screenshot: Erstellung eines neuen Pull Requests

    Screenshot: Erstellter Pull Request

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

Screenshot: Berichtsänderung

Wenn in einer der Regeln ein Fehler mit hohem Schweregrad vorliegt, können Sie den Pull Request nicht abschließen und die Änderungen wieder im Mainbranch zusammenführen.

Screenshot: Abgeschlossener Pull Request

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