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

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-byggpipeline 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-byggpipelinen för att verifiera utvecklingskvaliteten. Build-körningen utför följande åtgärder:

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-bygg-pipelinen för att inspektera den semantiska modellen och rapportens utvecklingskvalitet.

Kommentar

I det här exemplet använder bygg-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:

• Tabellredigeraren och metodtipsregler
• PBI-inspektör

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 – Anslut Fabric-arbetsyta till Azure DevOps

Anslut din Fabric-arbetsyta till Azure 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:

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

Så här skapar du en ny bygg-pipeline:

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

   

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

   

   

3. Välj Startpipeline.

   

   Följande YAML-kod visas i redigeraren:

   

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

   

   

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

   

   

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

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

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

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

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 bygg-pipelinen så att den körs med varje pull-begäran.

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

   

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

   

   

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:

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.

   

   

   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.

   

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

   

   

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

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

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