Dela via

Power BI Project (PBIP) och Azure DevOps bygger pipelines för validering

  • Artikel

Genom att kombinera Fabric Git-integrering med Azure DevOps kan du ansluta en arbetsyta till en gren på en Azure DevOps-lagringsplats och synkroniseras automatiskt mellan dem.

Genom att integrera PBIP-formatet med Azure DevOps kan du använda Azure Pipelines för att automatisera CI/CD-pipelines (Continuous Integration/Continuous Deployment ). Dessa pipelines bearbetar PBIP-metadatafilerna och tillämpar en serie kvalitetskontroller på din utveckling innan de distribueras till produktionssystemet.

I den här artikeln fokuserar vi på kontinuerlig integrering och beskriver hur du skapar en Azure DevOps-pipeline som garanterar bästa praxis för alla semantiska modeller och rapporter i en Infrastruktur-arbetsyta. Genom att implementera automatiserade kvalitetstester kan du förhindra vanliga misstag och förbättra teamets effektivitet. Den här metoden säkerställer till exempel att nya teammedlemmar följer etablerade standarder för semantisk modell och rapportutveckling.

Läs mer om PBIP- och Fabric Git-integrering i projektöversikt och Översikt över Fabric Git-integrering.

Följande diagram illustrerar scenariot från slutpunkt till slutpunkt med två utvecklingsarbetsflöden som utlöser Azure DevOps-pipelinen för att verifiera utvecklingskvaliteten. Pipelinekörningen utför följande åtgärder:

Diagram som visar arbetsflödet för DevOps-pipelinen.

  1. Användare 1 utvecklar med Power BI Desktop.

    1. Skapa en gren från main med VS Code (funktion/datasetchange)
    2. Göra ändringar i semantisk modell med Power BI Desktop
    3. Checka in ändringar i fjärrlagringsplatsens gren med VS Code
    4. Skapa pull-begäran till huvudgrenen med Hjälp av Azure DevOps

  2. Samtidigt utvecklar användare 2 med hjälp av en annan infrastrukturarbetsyta.

    1. Skapa gren från main med hjälp av Fabric Git (funktion/reportchange)
    2. Göra rapportändringar på arbetsytan Infrastruktur
    3. Checka in ändringar i fjärrlagringsplatsens gren med hjälp av Fabric Git
    4. Skapa pull-begäran till huvudgrenen med Hjälp av Azure DevOps

  3. Teamledningen granskar pull-begäranden och synkroniserar ändringarna till teamarbetsytan med hjälp av Fabric Git.

  4. Pull Request utlöser Azure DevOps-pipelinen för att inspektera den semantiska modellen och rapportera utvecklingskvalitet.

Kommentar

I det här exemplet använder pipelinen två communityverktyg med öppen källkod som gör det möjligt för en utvecklare att tillämpa (anpassningsbara) metodregler på metadata för semantiska modeller och rapporter i en Power BI Project-mapp:

En metod som liknar exemplet i den här artikeln skulle gälla för andra community-verktyg. Den här artikeln går inte in på detaljerna i de community-verktyg som nämnts tidigare eller skapa och redigera regler. Mer detaljerad information om dessa ämnen finns i länkarna som tillhandahålls. Fokus i den här artikeln ligger på processen att upprätta en kvalitetsgrind mellan källkontroll och infrastrukturarbetsyta. Det är viktigt att observera att de refererade communityverktygen har utvecklats av tredjepartsdeltagare, och Microsoft erbjuder inte support eller dokumentation för dem.

Steg 1 – Ansluta Fabric-arbetsytan till Azure DevOps

Anslut din Infrastruktur-arbetsyta till Azure DevOps:

Skärmbild som visar Git-anslutningen till DevOps.

När Fabric Git-integreringen är klar med att exportera dina arbetsyteobjekt innehåller Azure DevOps-grenen en mapp för varje objekt på arbetsytan:

Skärmbild som visar Azure DevOps-grenen med mappar för olika arbetsyteobjekt.

Steg 2 – Skapa och köra en Azure DevOps-pipeline

Så här skapar du en ny pipeline:

  1. På fliken Pipelines i den vänstra navigeringsmenyn väljer du Skapa pipeline :

    Skärmbild som visar hur du skapar en pipeline.

  2. Välj Azure Repos Git och välj den första lagringsplatsen (samma lagringsplats som är ansluten till arbetsytan Infrastruktur):

    Skärmbild som visar Azure-lagringsplatsen Git vald som kodkälla för pipelinen.

    Skärmbild som visar den valda demo-ADObuild-lagringsplatsen.

  3. Välj Startpipeline.

    Skärmbild som visar ikonen för startpipelinen markerad.

    Följande YAML-kod visas i redigeraren:

    Skärmbild som visar YAML-standardkoden.

  4. Kopiera och klistra in YAML-koden från power BI-utvecklarlägespipelinen i pipelinen som du skapade:

    Skärmbild som visar YAML-kod som ska läggas till.

    Skärmbild som visar den andra delen av YAML-kod.

  5. Välj Spara och kör för att checka in din nya pipeline på lagringsplatsen.

    Skärmbild av en granskning av YAML-koden.

    Skärmbild som visar val av spara och kör.

Azure DevOps kör pipelinen och startar två byggjobb parallellt:

Skärmbild som visar hur Azure DevOps kör en pipeline.

  • Build_Datasets
    • Laddar ned binärfiler för tabellredigeraren.
    • Ladda ned standardregler för Best Practice Analyzer. Om du vill anpassa reglerna lägger du till en Rules-Dataset.json till lagringsplatsens rot.
    • Bläddra igenom alla semantiska modellobjektmappar och kör BPA-regler för tabellredigeraren.
  • Build_Reports
    • Ladda ned PBI Inspector-binärfiler.
    • Ladda ned standardregler för PBI Inspector. Om du vill anpassa reglerna lägger du till en Rules-Report.json till lagringsplatsens rot.
    • Bläddra igenom alla mappar för rapportobjektet och kör Power BI Inspector-regler.

När den är klar skapar Azure DevOps en rapport över alla varningar och fel som den påträffade:

Skärmbild som visar felrapport.

Välj på länken för att öppna en mer detaljerad vy över de två jobben:

Skärmbild som visar knappen Visa logg.

Skärmbild som visar expanderad fellogg.

Om rapporten eller semantikmodellen misslyckas med en regel med högre allvarlighetsgrad misslyckas bygget och felet är markerat:

Skärmbild som visar överstrykningsfel.

Steg 3 – Definiera grenprinciper

När pipelinen är igång aktiverar du Grenprinciper på huvudgrenen. Det här steget säkerställer att inga incheckningar kan göras direkt till main. En "pull-begäran" krävs alltid för att sammanfoga ändringar tillbaka till main och du kan konfigurera pipelinen så att den körs med varje pull-begäran.

  1. Välj branchens>huvudprinciper för grengren:>

    Skärmbild som visar grenprinciper.

  2. Konfigurera den skapade pipelinen som en byggprincip för grenen:

    Skärmbild som visar användargränssnittet för byggprincip.

    Skärmbild som visar den andra delen av användargränssnittet för byggprincip.

Steg 4 – Skapa pull-begäran

Om du återgår till din infrastrukturarbetsyta, gör en ändring i någon av rapporterna eller semantikmodellerna och försöker genomföra ändringen får du följande fel:

Skärmbild som visar felet att det inte går att checka in ändring.

Du kan bara göra ändringar i huvudgrenen via en pull-begäran. Så här skapar du en checkout för pull-begäranden med en ny gren för att göra ändringarna på:

Skapa en gren direkt från arbetsytan Infrastruktur:

  1. I fönstret Källkontroll väljer du på Checkout new branch (Checkout new branch ) och anger ett namn för grenen.

    Skärmbild som visar skärmen för källkontroll för att checka ut en ny gren.

    Skärmbild som visar hur du checkar ut en ny gren.

    Du kan också välja att utveckla inom en separat, isolerad arbetsyta eller i Power BI Desktop. Mer information finns i Utveckla med hjälp av en annan arbetsyta

  2. Checka in ändringarna i den nya grenen.

    Skärmbild som visar incheckningsändringar i grenen.

  3. Efter incheckningen skapar du en pull-begäran till huvudgrenen från Azure DevOps-portalen.

    Skärmbild som visar en ny pull-begäran som skapats.

    Skärmbild som visar skapad pull-begäran.

Arbetsflödet för pull-begäran tillåter inte bara att du verifierar och granskar ändringarna, utan utlöser även pipelinen automatiskt.

Skärmbild som visar rapportändring.

Om det finns ett fel med hög allvarlighetsgrad i någon av reglerna kan du inte slutföra pull-begäran och sammanfoga ändringarna till huvudgrenen igen.

Skärmbild av slutförd pull-begäran.

Läs mer om PBIP- och Fabric Git-integrering i blogginlägget.