Power BI Pro ject (PBIP) och Azure DevOps-byggpipelines för validering
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:
Användare 1 utvecklar med Power BI Desktop.
- Skapa en gren från main med VS Code (funktion/datasetchange)
- Göra ändringar i semantisk modell med Power BI Desktop
- Checka in ändringar i fjärrlagringsplatsens gren med VS Code
- Skapa pull-begäran till huvudgrenen med Hjälp av Azure DevOps
Samtidigt utvecklar användare 2 med hjälp av en annan infrastrukturarbetsyta.
- Skapa gren från main med hjälp av Fabric Git (funktion/reportchange)
- Göra rapportändringar på arbetsytan Infrastruktur
- Checka in ändringar i fjärrlagringsplatsens gren med hjälp av Fabric Git
- Skapa pull-begäran till huvudgrenen med Hjälp av Azure DevOps
Teamledningen granskar pull-begäranden och synkroniserar ändringarna till teamarbetsytan med hjälp av Fabric Git.
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 Pro ject-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 communityverktygen eller hur du skapar och redigerar regler. Mer detaljerad information om dessa ämnen finns i länkarna som tillhandahålls. Fokus i den här artikeln ligger på att upprätta en kvalitetsgrind process mellan källkontroll och en Fabric-arbetsyta. Det är viktigt att observera att de refererade communityverktygen har utvecklats av tredjepartsdeltagare och att Microsoft inte erbjuder support eller dokumentation för dem.
Steg 1 – Ansluta Fabric-arbetsytan till Azure DevOps
Anslut din Infrastruktur-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-pipeline
Så här skapar du en ny pipeline:
På fliken Pipelines i den vänstra navigeringsmenyn väljer du Skapa pipeline :
Välj Azure Repos Git och välj den första lagringsplatsen (lagringsplatsen som är ansluten till arbetsytan Fabric):
Välj Startpipeline.
Följande YAML-kod visas i redigeraren:
Kopiera och klistra in YAML-koden från power BI-utvecklarlägespipelinen i pipelinen som du skapade:
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 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:
Välj på länken för att öppna en mer detaljerad vy över de två jobben:
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 pipelinen så att den körs med varje pull-begäran.
Välj branchens>huvudprinciper för grengren:>
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:
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 Hantera Git-grenar
Checka in ändringarna i den nya grenen.
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 pipelinen automatiskt.
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.
Relaterat innehåll
Information om hur du synkroniserar din arbetsyta med Git-grenen, inklusive uppdatering av arbetsytan och incheckning av ändringar i Git finns i Kom igång med Git-integrering.
Tips om olika alternativ för att bygga CI/CD-processer i Fabric baserat på typiska kundscenarier finns i Välj det bästa arbetsflödesalternativet för Fabric CI/CD för dig.