Planering av Power BI-implementering: Utveckla innehåll och hantera ändringar

Kommentar

Den här artikeln är en del av planeringsserien för Power BI-implementering. Den här serien fokuserar främst på Power BI-upplevelsen i Microsoft Fabric. En introduktion till serien finns i Implementeringsplanering för Power BI.

Den här artikeln hjälper dig att utveckla innehåll och hantera ändringar som en del av hanteringen av innehållslivscykeln. Det är främst inriktat på:

• Center of Excellence (COE) och BI-team: De team som ansvarar för att övervaka Power BI i organisationen. De här teamen omfattar beslutsfattare som bestämmer hur de ska hantera livscykeln för Power BI-innehåll. Dessa team kan också innehålla roller som versionshanterare, som hanterar livscykeln för innehållsversioner eller tekniker som skapar och hanterar de komponenter som behövs för att effektivt använda och stödja livscykelhantering.
• Innehållsskapare och innehållsägare: Användare som skapar innehåll, som de vill publicera till Fabric-portalen för att dela med andra. Dessa personer ansvarar för att hantera livscykeln för det Power BI-innehåll som de skapar.

Livscykelhantering är de processer och metoder som du använder för att hantera innehåll från skapandet till dess slutliga tillbakadragning. I den första fasen av livscykelhantering planerar och utformar du innehåll, vilket innebär att du planerar och fattar viktiga beslut som påverkar din inställning till livscykelhantering. I den andra fasen utvecklar du innehåll och hanterar ändringar.

Det är viktigt att hantera innehållsändringar under livscykeln för att säkerställa ett effektivt samarbete mellan innehållsskapare och en stabil och konsekvent leverans av innehåll till konsumenterna.

Följande bild visar livscykeln för Power BI-innehåll och markerar steg två, där du utvecklar innehåll och hanterar ändringar.

Kommentar

En översikt över innehållslivscykelhantering finns i den första artikeln i den här serien.

Dricks

Den här artikeln fokuserar på viktiga beslut och överväganden som hjälper dig att utveckla innehåll och hantera ändringar under hela livscykeln. Mer information om hur du utvecklar innehåll och hanterar ändringar finns i:

• Vad är livscykelhantering i Microsoft Fabric?: Den här artikeln innehåller en teknisk introduktion och självstudiekurs om infrastrukturresurser för Git-integrering och distributionspipelines.
• Metodtips för livscykelhantering: Den här artikeln innehåller praktiska tips och vägledning för hur du använder livscykelhanteringsfunktionerna i Fabric och Power BI för att utveckla innehåll och hantera ändringar.
• Power BI Desktop OneDrive och SharePoint-integrering: Den här artikeln innehåller en översikt över alternativen för att använda och lagra filer som sparats i OneDrive för arbete och skola eller SharePoint när du utför versionskontroll med .pbix-filer.
• Kom igång med Git i Azure Repos: Den här serien med artiklar innehåller praktiska tips, självstudier och vägledning för att utföra källkontroll med hjälp av en Git-lagringsplats i Azure Repos.

Innehållsskapare och ägare bör hantera innehållsändringar med hjälp av versionskontroll. Versionskontroll är en metod för att hantera ändringar i filer eller kod på en central lagringsplats. Den här metoden underlättar effektivare samarbete och innehållshantering.

Andra fördelar med versionskontroll är möjligheten att:

• Sammanfoga ändringar från flera innehållsskapare och hantera sammanslagningskonflikter.
• Identifiera vilket innehåll som har ändrats och vad som har ändrats i innehållet.
• Länka innehållsändringar till specifika arbetsobjekt.
• Gruppera ändringar i distinkta versioner med versionshistorik.
• Återställa ändringar eller hela versioner av innehåll.

Dricks

Vi rekommenderar att du använder versionskontroll för allt innehåll som du skapar, där det är möjligt. Användning av versionskontroll har betydande fördelar både för innehållsskapare och konsumenter och minskar risken för avbrott på grund av filförlust eller oförmåga att återställa ändringar.

Det första steget för att konfigurera versionskontroll är att bestämma hur du ska utveckla innehåll.

Bestämma hur du ska utveckla innehåll

Beroende på hur du skapar innehåll kan du fatta olika beslut om hur du hanterar det. För Power BI-rapporter och semantiska modeller har till exempel en Power BI Desktop-fil (.pbix) färre alternativ för versionskontroll jämfört med Power BI Desktop-projektformatet (.pbip). Det beror på att en .pbix-fil är ett binärt format, medan .pbip-formatet innehåller textbaserat innehåll och metadata som kan läsas av människor. Med mänskligt läsbart innehåll och metadata blir det enklare att spåra modell- och rapportändringar med hjälp av källkontroll. Källkontroll är när du visar och hanterar ändringar i innehållet i dess kod och metadata.

Dricks

När du utvecklar semantiska modeller och rapporter med hjälp av Power BI Desktop rekommenderar vi att du använder .pbip-filer i stället för .pbix-filer. När du utvecklar semantiska modeller med hjälp av XMLA-verktyg rekommenderar vi att du använder TMDL-formatet (Tabular Model Definition Language) i stället för .bim-filer.

.pbip- och TMDL-formaten stöder enklare spårning och sammanslagning av ändringar på objektnivå. Det innebär att du kan visa och hantera ändringar i enskilda objekt, till exempel DAX-mått eller tabeller.

Power BI Desktop

Du kan använda Power BI Desktop för att skapa semantiska modeller eller rapporter, som du kan spara som antingen .pbix- eller .pbip-filer. Det finns ytterligare anpassade innehållsfiler som du också kan använda när du använder Power BI Desktop.När du använder Power BI Desktop för att skapa innehåll bör du fatta några viktiga beslut:

• Vilket filformat som ska användas: Du kan spara innehåll antingen som .pbix- eller .pbip-filer. Git-integrering kräver till exempel att du använder .pbip-filer, självbetjäningsskapare kan hitta .pbix-filer som är enklare att hantera och underhålla i Teams, SharePoint eller OneDrive.
• Så här hanterar du anpassat innehåll: Du kan lägga till teman, anpassade visuella objekt eller bilder i Power BI Desktop-filer, vilket kan kräva olika överväganden för livscykelhantering. När innehållsskapare till exempel skapar egna anpassade visuella objekt bör de spara och hantera den visuella definitionen i en separat fil.
• Så här hanterar du förhandsgranskningsfunktioner: Du kan välja att förhandsgranska funktioner eller inställningar i Power BI Desktop, vilket ändrar innehållet och hur du använder det. Du kan till exempel vidta ytterligare åtgärder för att verifiera innehåll som använder förhandsgranskningsfunktioner.

Webbredigering

Visst innehåll, till exempel dataflöden, instrumentpaneler och styrkort, kan bara skapas i Infrastrukturportalen. Du kan också skapa eller ändra innehåll, till exempel semantiska modeller, rapporter och sidnumrerade rapporter, både i Infrastrukturportalen eller med hjälp av lokala verktyg. När du skapar innehåll med hjälp av webbredigering bör du fatta några viktiga beslut:

• Så här hanterar du ändringar: Du kan göra ändringar i många objekttyper med hjälp av webbredigering, men dessa ändringar kan sparas direkt och skriva över tidigare versioner. Om du till exempel samarbetar med andra kanske du vill undvika webbredigering på delade objekt och i stället arbeta med din egen kopia.
• Så här hämtar du innehållssäkerhetskopior: Du kan skapa innehåll som rapporter eller semantiska modeller med hjälp av webbredigering, men dessa objekt kan inte laddas ned till lokala .pbix-filer. Du kan till exempel välja att säkerhetskopiera det här innehållet genom att hämta och lagra dess metadata.

Dricks

När du utvecklar dataflöden och styrkort rekommenderar vi att du hämtar objektdefinitionerna för att hantera ändringar och lagra en säkerhetskopia. Du kan automatisera hämtningen av dataflöden och styrkort med hjälp av REST-API:er för infrastrukturresurser. Mer specifikt kan du använda slutpunkterna Hämta dataflöde respektive Hämta styrkort .

Varning

Vissa innehåll, till exempel instrumentpaneler, har inte möjlighet att hämta en definition. För det här innehållet kan du inte enkelt spåra ändringar eller hämta en säkerhetskopia.

Andra verktyg

Du kan använda andra verktyg för att skapa eller hantera vissa typer av innehåll. De här verktygen kan ge ytterligare fördelar, passa ditt arbetsflöde bättre eller behövas för att hantera specifika funktioner eller innehållstyper. Du kan använda både andra Microsoft-verktyg eller verktyg från tredje part för att skapa och hantera innehåll. Andra verktyg som du kan använda för att skapa eller hantera innehåll är följande.

• Visual Studio eller Visual Studio Code: En integrerad utvecklingsmiljö där utvecklare kan skapa och hantera semantiska modeller eller Fabric-notebook-filer. Med både Visual Studio och Visual Studio Code kan utvecklare också utföra källkontrollhantering (SCM) genom att checka in och skicka lokala ändringar till en fjärrlagringsplats.
• Tabellredigerare: Ett verktyg från tredje part för att utveckla och hantera semantiska modeller.
• Excel: Ett klientverktyg för pivottabeller och liveanslutna tabeller som fungerar med en semantisk modell.
• Power BI Report Builder: Ett skrivbordsprogram för att skapa sidnumrerade rapportfiler (.rdl).

När du skapar innehåll med hjälp av andra verktyg bör du fatta några viktiga beslut:

• Så här hanterar du licenser: Andra verktyg kan kräva ytterligare licenser som du bör hantera.
• Publicera innehåll: Andra verktyg kan kräva ytterligare steg för att publicera innehåll, till exempel genom att använda XMLA-slutpunkter eller Power BI REST-API:er.

När du har bestämt dig för hur du ska skapa innehåll måste du välja var du ska publicera och testa innehåll när du utvecklar det.

Bestäm hur du ska konfigurera och använda arbetsytor

När du utvecklar innehåll bör du använda flera arbetsytor (eller faser) för att separera produktionsinnehåll som används av organisationen från innehåll som utvecklas eller verifieras. Det finns flera fördelar med att använda separata arbetsytor för ditt innehåll:

• Du kan utveckla och testa innehåll utan att påverka det innehåll som används för närvarande. Detta förhindrar ändringar som kan orsaka oavsiktliga störningar i innehållet i produktionen.
• Du kan använda separata resurser för att utveckla och testa innehåll, till exempel med hjälp av separata datagatewayer eller infrastrukturresurser. Detta förhindrar att resurser som används för utveckling och testning stör produktionsarbetsbelastningar, vilket orsakar långsamma datauppdateringar eller rapporter.
• Du kan skapa en mer strukturerad process för att utveckla, testa och släppa innehåll genom att ha diskreta miljöer för vart och ett av dessa steg. Detta hjälper dig att förbättra produktiviteten.

I Fabric och Power BI rekommenderar vi att du använder separata infrastrukturarbetsytor enligt beskrivningen i planeringsartiklarna på klient- och arbetsytenivå .

Viktigt!

Att använda separata miljöer är ett viktigt steg för att säkerställa att livscykelhanteringsmetoden för innehåll lyckas.

Det finns flera sätt att använda Infrastrukturarbetsytor för att separera miljöer. Utöver din lokala miljö använder du vanligtvis två eller flera arbetsytor för att hantera innehåll under livscykeln.

Besvara följande frågor när du planerar hur du ska använda separata arbetsytor under hela innehållets livscykel:

• Hur många arbetsytor behöver du?
• Kommer du att separera arbetsytor efter objekttyp?
• Vem har åtkomst till varje arbetsyta?
• Kommer arbetsytorna att tillhöra en infrastrukturdistributionspipeline, eller kommer du att samordna distributionen med hjälp av andra metoder, till exempel genom att använda Azure Pipelines?
• Hur hanterar du publicering mellan arbetsytor? Behöver du till exempel se till att rapporter i en testarbetsyta för rapporter ansluter till semantiska modeller på en separat testarbetsyta för dataobjekt?
• Behöver du också använda separata stödresurser för objekt i produktionsarbetsytor, till exempel ett separat lokalt datagatewaykluster?

Följande avsnitt innehåller en översikt på hög nivå över de olika metoder som du kan använda för att separera arbetsytor för att underlätta livscykelhantering.

Kommentar

Följande avsnitt fokuserar på hur du kan konfigurera och använda separata arbetsytor. Du kan distribuera innehåll till dessa arbetsytor med någon av följande fyra metoder:

• Publicera från Power BI Desktop.
• Distribuera innehåll från en annan arbetsyta med hjälp av infrastrukturdistributionspipelines.
• Synkronisera innehåll från en fjärransluten Git-lagringsplats med hjälp av Git-integrering.
• Distribuera innehåll programmatiskt med hjälp av REST-API:er för infrastrukturresurser, Power BI REST-API:er eller XMLA-slutpunkter.

Mer information om dessa metoder för att distribuera innehåll finns i Steg 4: Distribuera innehåll senare i den här serien.

Test- och produktionsarbetsytor

När du levererar enklare innehåll som inte är kritiskt för organisationen kan det ofta räcka med två arbetsytor. I det här scenariot har innehållsskapare vanligtvis begränsat samarbete om samma objekt och utvecklar innehåll lokalt.

Följande diagram visar ett högnivåexempel på hur du kan använda separata miljöer med endast en test- och produktionsarbetsyta.

Diagrammet visar följande processer och komponenter för att separera arbetsytor i den här metoden.

Artikel	Beskrivning
	Innehållsskapare utvecklar innehåll i sin lokala miljö.
	När det är klart publicerar innehållsskapare innehåll till en testarbetsyta. Innehållsskapare kan utveckla innehåll som bara kan skapas med webbredigering och utföra innehållsverifiering på testarbetsytan.
	När det är klart distribuerar innehållsskapare innehåll till en produktionsarbetsyta. På produktionsarbetsytan distribuerar innehållsskapare innehåll genom att publicera en Power BI-app eller dela innehåll från arbetsytan.

Kommentar

Det finns många olika sätt att konfigurera och använda separata arbetsytor och distribuera innehåll mellan dessa arbetsytor. Vi rekommenderar dock att du inte utför lokal utveckling och sedan publicerar innehåll direkt till en produktionsarbetsyta. Detta kan leda till störningar och fel som kan förhindras.

Arbetsytor för utveckling, testning och produktion

När du levererar affärskritiskt innehåll använder du vanligtvis tre eller flera separata arbetsytor. I det här scenariot samarbetar innehållsskapare ofta på ytterligare en utvecklingsarbetsyta som innehåller den senaste versionen av lösningen.

Följande diagram visar ett högnivåexempel på hur du kan använda separata miljöer med en arbetsyta för utveckling, testning och produktion.

Diagrammet visar följande processer och komponenter för att separera arbetsytor i den här metoden.

Artikel	Beskrivning
	Innehållsskapare utvecklar innehåll i sin lokala miljö.
	När det är klart publicerar innehållsskapare innehåll till en utvecklingsarbetsyta. På utvecklingsarbetsytan kan innehållsskapare utveckla innehåll som bara kan skapas med webbredigering. Innehållsskapare kan också verifiera innehåll på utvecklingsarbetsytan.
	När det är klart distribuerar innehållsskapare innehåll till en testarbetsyta. På testarbetsytan validerar användarna innehåll, antingen på arbetsytan eller i en app.
	När det är klart distribuerar innehållsskapare innehåll till en produktionsarbetsyta. På produktionsarbetsytan distribuerar innehållsskapare innehåll genom att publicera en Power BI-app eller dela innehåll från arbetsytan.

Kommentar

Du kan använda upp till tio olika miljöer med distributionspipelines. Du kanske till exempel vill ha en förproduktionsmiljö mellan test och produktion som är specifikt för särskilda typer av validering, till exempel prestandatestning.

Privat arbetsyta med Git-integrering

När de levererar affärskritiskt innehåll kan varje utvecklare också använda sin egen privata arbetsyta för utveckling. I det här scenariot tillåter en privat arbetsyta innehållsskapare att testa innehåll i Infrastrukturportalen eller använda funktioner som schemalagd uppdatering utan att riskera störningar för andra i utvecklingsteamet. Innehållsskapare kan också utveckla innehåll i Fabric-portalen här, till exempel dataflöden. Privata arbetsytor kan vara ett bra val när du hanterar innehållsändringar med hjälp av Git-integrering tillsammans med Azure DevOps.

Kommentar

Azure DevOps är en uppsättning tjänster som integreras med Power BI och Fabric för att hjälpa dig att planera och samordna innehållslivscykelhantering. När du använder Azure DevOps på det här sättet använder du vanligtvis följande tjänster:

• Azure Repos: Gör att du kan skapa och använda en fjärransluten Git-lagringsplats, som är en fjärrlagringsplats som du använder för att spåra och hantera innehållsändringar.
• Azure Pipelines: Gör att du kan skapa och använda en uppsättning automatiserade uppgifter för att hantera, testa och distribuera innehåll från en fjärrlagringsplats till en arbetsyta.
• Azure-testplaner: Gör att du kan utforma tester för att verifiera lösningen och automatisera kvalitetskontroll tillsammans med Azure Pipelines.
• Azure Boards: Gör att du kan använda tavlor för att spåra uppgifter och planer som arbetsobjekt och länka eller referera till arbetsobjekt från andra Azure DevOps-tjänster.
• Azure Wiki: Gör att du kan dela information med deras team för att förstå och bidra till innehåll.

Följande diagram visar ett högnivåexempel på hur du kan använda separata miljöer med hjälp av en privat arbetsyta med Git-integrering.

Kommentar

Diagrammet visar separata utvecklare som arbetar med separata grenar av en lösning (gren ett och gren två) innan de sammanfogar sina ändringar i en huvudgren. Det här är en förenklad beskrivning av en Git-förgreningsstrategi för att illustrera hur utvecklare kan integrera sina ändringar med en fjärransluten Git-lagringsplats och dra nytta av Git-integrering i Infrastrukturresurser.

Diagrammet visar följande processer och komponenter för att separera arbetsytor i den här metoden.

Artikel	Beskrivning
	Varje innehållsskapare utvecklar innehåll i sin egen lokala miljö.
	När de är klara checkar innehållsskaparna in och push-överför sina ändringar till en fjärrlagringsplats, till exempel en Azure Repos Git-lagringsplats.
	På git-fjärrlagringsplatsen spårar och hanterar innehållsskapare innehållsändringar med hjälp av källkontroll och förgrenar och sammanfogar innehåll för att underlätta samarbete.
	Innehållsskapare synkroniserar en gren av fjärrlagringsplatsen med en privat arbetsyta. Efter synkroniseringen visas de senaste ändringarna som en skapare checkar in och push-överför till grenen på den privata arbetsytan. Olika innehållsskapare arbetar på egna, separata grenar när de gör ändringar.
	På de privata arbetsytorna kan innehållsskapare utveckla innehåll med hjälp av webbredigering och verifiera sina egna ändringar. Ändringar av innehåll som görs genom webbredigering kan synkroniseras med grenen på Git-lagringsplatsen när innehållsskapare checkar in och push-överför ändringarna från arbetsytan. Olika innehållsskapare arbetar på sina egna, separata privata arbetsytor.
	När de är klara utför innehållsskapare en pull-begäran för att sammanfoga sina ändringar i huvudgrenen i lösningen.
	När ändringarna har sammanfogats synkroniseras huvudgrenen med arbetsytan utveckling.
	På utvecklingsarbetsytan kan innehållsskapare utveckla innehåll som inte stöds av Fabric Git-integrering, till exempel instrumentpaneler. Innehållsskapare validerar också den integrerade lösningen som innehåller alla de senaste ändringarna.
	När det är klart distribuerar innehållsskapare innehåll till en testarbetsyta. På testarbetsytan utför användarna godkännandetestning av innehåll.
	När det är klart distribuerar innehållsskapare innehåll till en produktionsarbetsyta. På produktionsarbetsytan distribuerar innehållsskapare innehåll genom att publicera en Power BI-app eller dela innehåll från arbetsytan.

Stödresurser för arbetsytor

När du använder separata miljöer bör du också överväga hur detta påverkar olika stödresurser som du använder i dessa miljöer. För de här stödresurserna bör du överväga om du också behöver dela upp dem i samma antal steg, eller hur du ska samordna deras användning i de här miljöerna.

• Gatewayer: Överväg att använda separata lokala datagatewaykluster och VNet-gatewayer för produktionsarbetsbelastningar. Detta är fördelaktigt för att förhindra avbrott, men också för att säkerställa drifttid när du behöver uppdatera dessa gatewayer.
• Appar: Överväg att ha separata appar för test- och produktionsarbetsytor. Det går inte att distribuera eller kopiera appar mellan faser. Appar på testarbetsytan är avsedda att hjälpa dig att testa innehåll och appupplevelsen innan du distribuerar ändringar till produktionsarbetsytan. Appar på produktionsarbetsytan är avsedda att leverera innehåll till slutanvändare i en strukturerad miljö.
• Azure DevOps: Om du tänker använda Azure DevOps för att samarbeta och samordna källkontroll och distribution bör du överväga hur du ska använda grenar och Azure Pipelines för att distribuera innehåll mellan dessa miljöer. Mer information om hur du använder Azure Pipelines för att distribuera innehåll finns i Steg 4: Distribuera innehåll.

När du har bestämt dig för hur du ska konfigurera och använda arbetsytor är nästa steg att bestämma hur du ska utföra versionskontroll för att spåra och hantera innehållsändringar.

Bestäm hur du ska använda versionskontroll

I Power BI kan du utföra versionskontroll antingen med Hjälp av SharePoint/OneDrive eller genom att använda en fjärransluten Git-lagringsplats, till exempel Azure Repos, som är en komponent i Azure DevOps. I båda metoderna lägger du till lokala innehållsfiler på en fjärrlagringsplats för att spåra och hantera ändringar. Vi rekommenderar att du endast använder SharePoint eller OneDrive för mindre och enklare projekt, eftersom det saknar funktioner och robusthet för att stödja större eller mer komplicerade scenarier.

Här följer några allmänna överväganden som hjälper dig att konfigurera och använda versionskontroll.

• Aviseringar: Du bör konfigurera aviseringar för när andra lägger till, tar bort eller ändrar viktiga filer.
• Omfång: Definiera omfånget för fjärrlagringsplatsen tydligt. Helst är omfattningen för fjärrlagringsplatsen identisk med omfattningen för de underordnade arbetsytor och appar som du använder för att leverera innehåll till konsumenter.
• Åtkomst: Du bör konfigurera åtkomst till fjärrlagringsplatsen med hjälp av en liknande behörighetsmodell som du har konfigurerat för dina behörigheter för distributionspipelines och arbetsyteroller. Innehållsskapare behöver åtkomst till fjärrlagringsplatsen.
• Dokumentation: Lägg till textfiler på fjärrlagringsplatsen för att beskriva fjärrlagringsplatsen och dess syfte, ägarskap, åtkomst och definierade processer.

I följande avsnitt beskrivs varje metod och viktiga överväganden för att avgöra vilken du ska använda.

Versionskontroll med hjälp av SharePoint eller OneDrive för arbete och skola

SharePoint har inbyggd versionskontroll för filer. Innehållsskapare kan utveckla semantiska modeller eller rapporter lokalt och deras ändringar synkroniseras till ett SharePoint- eller OneDrive för arbets- och skoldokumentbibliotek.

Dricks

Använd endast SharePoint eller OneDrive för versionskontroll i enklare, mindre scenarier, till exempel självbetjäning av innehållspublicering. För större eller mer komplicerade scenarier bör du överväga att utföra källkontroll med hjälp av en fjärransluten Git-lagringsplats.

Följande diagram visar en översikt på hög nivå över hur du utför versionskontroll med hjälp av SharePoint eller OneDrive.

Diagrammet beskriver följande processer och komponenter.

Artikel	Beskrivning
	Innehållsskapare utvecklar semantiska modeller och rapporter i sin lokala miljö och sparar dessa modeller och rapporter som .pbix-filer.
	När de är klara sparar innehållsskapare sina ändringar, som de synkroniserar till ett fjärranslutet SharePoint- eller OneDrive för arbets- och skolbibliotek.
	I fjärrbiblioteket spårar innehållsskapare ändringar på filnivå som underlättar versionskontrollen.
	Innehållsskapare kan länka en publicerad semantisk modell eller rapport till en .pbix-fil för att underlätta OneDrive-uppdatering. OneDrive-uppdateringen publicerar automatiskt innehållsändringar varje timme.
	På arbetsytan Infrastruktur ser innehållsskapare ändringarna i Power BI-innehåll när OneDrive-uppdateringen har slutförts.

Viktigt!

Du kan bara utföra versionskontroll med hjälp av SharePoint- eller OneDrive för Power BI Desktop-filer som innehåller semantiska modeller eller rapporter. Du kan inte enkelt utföra versionskontroll med hjälp av SharePoint eller OneDrive för andra Power BI-objekttyper som dataflöden eller för typer av infrastrukturobjekt som notebook-filer. För dessa andra objekttyper bör du utföra versionskontroll med hjälp av en fjärransluten Git-lagringsplats, till exempel Azure Repos.

För att sammanfatta kan innehållsskapare länka en publicerad semantisk modell eller rapport till en .pbix-fil som lagras i ett SharePoint- eller OneDrive för arbets- och skolbibliotek. Med den här metoden behöver innehållsskapare inte längre publicera semantikmodellen för att se ändringar. I stället visas ändringarna efter en automatisk OneDrive-uppdatering, som sker varje timme. Även om det är praktiskt, kommer den här metoden med vissa överväganden, och det kan inte enkelt vändas.

Även om det är enkelt att konfigurera och hantera har versionskontrollen med SharePoint eller OneDrive fler begränsningar. Det går till exempel inte att visa ändringar i innehållet och det går inte heller att jämföra versioner. Dessutom går det inte att konfigurera mer avancerade processer för att hantera dessa ändringar (till exempel förgrenings- eller pull-begäranden som beskrivs senare i den här artikeln).

Överväg att använda SharePoint eller OneDrive för att spåra och hantera ändringar i följande scenarier:

• Innehållet består endast av semantiska modeller eller rapporter som sparats som .pbix-filer.
• Självbetjäningsanvändare skapar och hanterar innehållet.
• Innehållsskapare samarbetar med hjälp av Microsoft Teams.
• Innehållsskapare är oerfarna med Git och källkontrollhantering.
• Innehållsskapare hanterar ett enda objekt med begränsad komplexitet och samarbete.
• .pbix-filerna har en känslighetsetikett som krypterar innehållet.

Kommentar

OneDrive och SharePoint har stöd för innehåll som har känslighetsetiketter, förutom vissa begränsade scenarier. Fabric Git-integrering stöder däremot inte känslighetsetiketter.

Undvik att använda SharePoint eller OneDrive för att spåra och hantera ändringar i följande scenarier:

• Innehållet består av andra objekttyper än semantiska modeller och rapporter.
• Innehållet är komplext eller stort i omfånget.
• Innehållsskapare måste samarbeta om samma objekt samtidigt.

I följande avsnitt beskrivs ytterligare överväganden för att effektivt använda versionskontroll med hjälp av SharePoint eller OneDrive med Power BI.

Microsoft Teams-integrering

Du kan använda dokumentbiblioteken från Microsoft Teams om innehållsskapare använder det för sitt samarbete. Dokumentbibliotek är SharePoint-webbplatser och användning av dokumentbiblioteken (i stället för en separat SharePoint-webbplats eller OneDrive-mapp) säkerställer centralisering av innehåll, filer och samarbete.

Inchecknings- och utcheckningsfiler

Du bör checka ut filer som du arbetar med för att undvika eventuella ändringskonflikter. När ändringarna är klara checkar du in filerna med kommentarer som beskriver ändringen. Genom att checka in och checka ut filer kan du förbättra samarbetet mellan innehållsskapare när du använder SharePoint eller OneDrive för arbete och skola för versionskontroll. Om du checkar in och checkar ut filer med flera innehållsskapare kan du ändra SharePoint-webbplatsbiblioteket för att visa den senaste uppdateringen och kommentarerna från den senaste incheckningen.

Versionshistorik

Se till att du säkerhetskopierar innehåll till en separat plats i händelse av oväntade avbrott i sharePoint-webbplatsdokumentbiblioteket. Du bör också ange gränser för antalet versioner som lagras på SharePoint-webbplatsen och ta bort gamla versioner. Detta säkerställer att versionshistoriken förblir meningsfull och inte tar upp för mycket utrymme.

För mer avancerad versionskontroll kan du lagra filer på en fjärrlagringsplats som Azure Repos och hantera ändringar med hjälp av källkontroll.

Källkontroll med hjälp av en fjärransluten Git-lagringsplats

En fjärransluten Git-lagringsplats underlättar källkontroll av filer, vilket gör det möjligt för innehållsskapare att spåra och hantera ändringar. I korthet kan innehållsskapare utveckla innehåll antingen lokalt eller i Power BI-tjänst och sedan checka in och skicka ändringarna till en fjärransluten Git-lagringsplats som Azure Repos

Kommentar

Du kan också utföra källkontroll av ditt innehåll utan att använda Git-integrering. I det här scenariot spårar och hanterar du fortfarande innehållsändringar på en fjärransluten Git-lagringsplats, men du distribuerar innehåll med hjälp av rest-API:er eller XMLA-slutpunkter för läsning/skrivning. Mer information om dessa metoder för att distribuera innehåll finns i Steg 4: Distribuera innehåll.

Följande diagram visar en översikt på hög nivå över hur du utför källkontroll genom att

Diagrammet beskriver följande processer och komponenter.

Artikel	Beskrivning
	Innehållsskapare utvecklar semantiska modeller och rapporter i sin lokala miljö och sparar dessa modeller och rapporter som .pbip-filer. Innehållsskapare kan också utveckla semantiska modeller och spara modellmetadata.
	När de är klara sparar innehållsskapare sina ändringar, som de checkar in och skickar till en fjärransluten Git-lagringsplats med jämna mellanrum.
	På git-fjärrlagringsplatsen spårar innehållsskapare ändringar på objektnivå, vilket underlättar versionskontrollen. Innehållsskapare kan också skapa grenar för att arbeta med innehåll och sammanfoga sina ändringar i en enda gren med hjälp av pull-begäranden.
	Innehållsskapare kan synkronisera innehåll från fjärrlagringsplatsen med hjälp av Git-integrering. De kan också distribuera innehåll med hjälp av andra metoder, till exempel Azure Pipelines tillsammans med REST-API:erna.
	På arbetsytan Infrastruktur ser innehållsskapare ändringarna av Power BI-innehåll när synkroniseringen eller distributionen har slutförts. Innehållsskapare kan skapa innehåll som dataflöden eller notebook-filer på arbetsytan. Om de använder Git-integrering länkar innehållsskapare den här arbetsytan till en viss gren av fjärrlagringsplatsen.
	Innehållsskapare kan checka in och skicka ändringar från en arbetsyta till fjärrlagringsplatsen med hjälp av Git-integrering. Dessa ändringar kan importera objektdefinitioner för innehåll som stöds som skapats på arbetsytan, till exempel dataflöden och notebook-filer.

Sammanfattningsvis lagrar innehållsskapare .pbip-filer, metadatafiler och dokumentation på en central Azure Repos-fjärrlagringsplats. Dessa filer kureras av en teknisk ägare. Medan en innehållsskapare utvecklar en lösning ansvarar en teknisk ägare för att hantera lösningen och granska ändringarna och slå samman dem till en enda lösning. Azure Repos innehåller mer avancerade alternativ för att spåra och hantera ändringar jämfört med SharePoint och OneDrive. Det är viktigt att ha en väldokumenterad, dokumenterad lagringsplats eftersom den utgör grunden för allt innehåll och allt samarbete.

Överväg att använda källkontroll för att spåra och hantera ändringar i följande scenarier:

• Centraliserade eller decentraliserade team skapar och hanterar innehållet.
• Innehållsskapare samarbetar med hjälp av Azure DevOps.
• Innehållsskapare är bekanta med Git, källkontrollhantering eller DataOps-principer.
• Innehållsskapare hanterar komplext eller viktigt innehåll eller förväntar sig att innehållet skalar och växer i komplexitet och betydelse.

Här följer några förutsättningar och överväganden som hjälper dig att effektivt använda källkontroll med Azure DevOps.

• Git: För att checka in och skicka ändringar till en fjärrlagringsplats måste innehållsskapare ladda ned och installera Git. Git är ett distribuerat versionskontrollsystem som spårar ändringar i dina filer. Mer information om grunderna i Git finns i Vad är Git?.
• Verktyg: Om du vill använda Git måste innehållsskapare antingen använda ett kommandoradsgränssnitt (CLI) eller en grafisk användargränssnittsklient (GUI) för SCM, till exempel Visual Studio eller Visual Studio Code.
• Licenser och behörigheter: Om du vill skapa och använda en Azure Repos Git-lagringsplats måste innehållsskapare ha följande:
  • Åtkomstnivå inställd på Basic (till skillnad från intressent).
  • Tillhör en organisation och ett projekt.
  • Lämpliga lagringsplatsbehörigheter.
• Fabric Git-integrering: Om du vill synkronisera innehåll på en fjärrlagringsplats med en Microsoft Fabric-arbetsyta använder innehållsskapare Fabric Git-integrering. Detta är viktigt för att spåra och hantera ändringar av innehåll som skapas i Infrastrukturportalen, till exempel dataflöden.

Dricks

För att underlätta källkontroll med lokal utveckling rekommenderar vi att du använder ett klientprogram som Visual Studio Code. Du använder Power BI Desktop för att utveckla innehåll och sedan kan du använda Visual Studio Code för att utföra källkontrollhantering av innehållet genom att mellanlagra, checka in och skicka ändringar till fjärrlagringsplatsen.

Varning

Fabric Git-integrering har vissa begränsningar med de objekt och scenarier som stöds. Se till att du först kontrollerar om Fabric Git-integrering passar bäst för ditt specifika scenario eller om du bör använda en annan metod för att implementera källkontroll.

Dessutom stöds inte känslighetsetiketter med Fabric Git-integrering, och export av objekt med känslighetsetiketter kan inaktiveras. Om ditt innehåll har känslighetsetiketter bör du planera hur du kan uppnå versionskontroll samtidigt som du respekterar dina principer för dataförlustskydd.

En viktig fördel med att använda källkontroll med Azure Repos är förbättrat samarbete mellan innehållsskapare och mer anpassning och tillsyn av innehållsändringar och distribution.

Följande diagram visar en översikt på hög nivå över hur Azure DevOps möjliggör samarbete med källkontroll.

Kommentar

Det föregående diagrammet visar ett exempel på hur du samarbetar med hjälp av Azure DevOps. Välj en metod som bäst passar behoven och sättet att arbeta i ditt team.

Diagrammet visar följande användaråtgärder, processer och funktioner.

Artikel	Beskrivning
	En innehållsskapare skapar en ny, kortlivad gren genom att klona huvudgrenen, som innehåller den senaste versionen av innehållet. Den nya grenen kallas ofta för funktionsgrenen, eftersom den används för att utveckla en specifik funktion eller åtgärda ett specifikt problem.
	Innehållsskapare checkar in sina ändringar på en lokal lagringsplats under utvecklingen.
	Innehållsskapare länkar sina ändringar till arbetsobjekt som hanteras i Azure Boards. Arbetsobjekt beskriver specifika utvecklingar, förbättringar eller buggkorrigeringar som är begränsade till deras gren.
	Innehållsskapare genomför regelbundet sina ändringar. När det är klart publicerar innehållsskapare sin gren till fjärrlagringsplatsen.
	För att testa sina ändringar distribuerar innehållsskapare sin lösning till en isolerad arbetsyta för utveckling (visas inte i det här diagrammet). Innehållsskapare kan också synkronisera funktionsgrenen till arbetsytan med hjälp av Fabric Git-integrering.
	Innehållsskapare och innehållsägare dokumenterar lösningen och dess processer i en Azure Wiki, som är tillgänglig för hela utvecklingsteamet.
	När det är klart öppnar innehållsskapare en pull-begäran för att sammanfoga funktionsgrenen till huvudgrenen.
	En teknisk ägare ansvarar för att granska pull-begäran och sammanfoga ändringar. När de godkänner pull-begäran sammanfogar de funktionsgrenen till huvudgrenen.
	En lyckad sammanslagning utlöser distributionen av lösningen till en utvecklingsarbetsyta med hjälp av en Azure Pipeline (visas inte i det här diagrammet). När du använder Fabric Git-integrering synkroniseras huvudgrenen med utvecklingsarbetsytan.
	Versionshanteraren utför en slutlig granskning och godkännande av lösningen. Det här versionsgodkännandet förhindrar att lösningen publiceras innan den är klar. I företagsinnehållspublicering planerar och samordnar en versionshanterare vanligtvis innehållsversionen för att testa och produktionsarbetsytor. De samordnar och kommunicerar med innehållsskapare, intressenter och användare.
	När versionshanteraren godkänner versionen förbereder Azure Pipelines automatiskt lösningen för distribution. En Azure Pipeline kan också utlösa en distributionspipeline för att höja upp innehåll mellan arbetsytor.
	Användare testar och validerar innehåll på testarbetsytan. När du använder Git-integrering med Azure Pipelines för distribution synkroniseras inte testarbetsytan med någon gren.
	När användarna har godkänt och verifierat ändringar utför versionshanteraren en slutlig granskning och godkännande av lösningen för distribution till produktionsarbetsytan.
	Användare visar innehåll som har publicerats till produktionsarbetsytan. När du använder Git-integrering med Azure Pipelines för distribution synkroniseras inte produktionsarbetsytan med någon gren.

I följande avsnitt beskrivs ytterligare överväganden för att effektivt använda källkontroll med hjälp av Azure DevOps och Power BI.

Viktigt!

Effektiv användning av förgrening, incheckningar, pull-begäranden och sammanslagningar är avgörande för att de flesta ska kunna dra nytta av källkontroll när du hanterar livscykeln för ditt Power BI-innehåll.

Använda grenar

Innehållsskapare samarbetar med hjälp av en förgreningsstrategi. Med en förgreningsstrategi kan enskilda innehållsskapare arbeta isolerat på sin lokala lagringsplats. När de är klara kombinerar de sina ändringar som en enda lösning på fjärrlagringsplatsen. Innehållsskapare bör begränsa sitt arbete till grenar genom att länka dem till arbetsobjekt för specifika utvecklingar, förbättringar eller felkorrigeringar. Varje innehållsskapare skapar sin egen gren av fjärrlagringsplatsen för sitt arbete. Arbetet med den lokala lösningen utförs och skickas till en version av grenen på fjärrlagringsplatsen med ett beskrivande incheckningsmeddelande. Ett incheckningsmeddelande beskriver de ändringar som gjorts i incheckningen.

När du använder en förgreningsstrategi för att hantera Fabric-innehåll bör du tänka på följande faktorer.

• Vilka skapare av greninnehåll ska klona för sitt eget arbete. Om dessa grenar till exempel är en klon av huvudgrenen (kallas trunkbaserad utveckling) eller om de är andra grenar, till exempel versionsgrenar för specifika, planerade versioner av innehåll.
• Om du ska omfångsbegränsa specifikt arbete för distinkta innehållsversioner med hjälp av versionsgrenar.
• Vilka grenar ansluter till vilken arbetsyta när du använder Fabric Git-integrering.

Dricks

Se Anta en Git-förgreningsstrategi för specifik vägledning och rekommendationer om hur du bäst använder en förgreningsstrategi för att effektivt underlätta samarbete.

Batchändringar i incheckningar

När de utvecklar innehåll bör skaparna regelbundet mellanlagra ändringar i batchar (eller grupper). Dessa ändringar bör åtgärda ett specifikt arbetsobjekt för lösningen (till exempel en funktion eller ett problem). När de är klara genomför innehållsskaparna dessa mellanlagrade ändringar.

Batchbearbetningsändringar på det här sättet har flera fördelar.

• Det hjälper till att strukturera utvecklingen och ger innehållsskapare en chans att granska och dokumentera de ändringar som de har grupperat.
• Det förbättrar anpassningen mellan planering och utveckling, vilket gör det enklare att länka funktioner och problem och få insyn i hur arbetet fortsätter.
• Tekniska ägare kan enklare granska pull-begäranden från innehållsskapare om ändringarna batchats korrekt och har tydliga incheckningsmeddelanden.

När du mellanlagrar och genomför ändringar i Power BI-innehåll bör du tänka på följande faktorer.

• Oavsett om du ska mellanlagra och checka in ändringar från en lokal lagringsplats eller från arbetsytan Infrastrukturresurser.
• Placera .pbip-filer i mappar på den översta nivån när du lagrar flera modeller eller rapporter på en enda lagringsplats. Detta gör det enklare att identifiera och gruppera ändringar som du gör.
• Ignorera oskadliga eller ohjälpsamma metadataändringar med hjälp av en gitignore-fil eller en .gitattributes-fil. Detta säkerställer att alla ändringar du genomför är meningsfulla.

Dricks

Se Spara ditt arbete med incheckningar för specifik vägledning och rekommendationer om hur du mellanlagrar och checkar in ditt arbete på en Git-lagringsplats.

Skapa pull-begäranden för att sammanfoga ändringar

Om du vill sammanfoga ändringarna öppnar en innehållsskapare en pull-begäran. En pull-begäran är en inlämning för peer-granskning som kan leda till sammanslagning av det arbete som utförs i en enda lösning. Sammanslagning kan leda till konflikter som måste lösas innan grenen kan sammanfogas. Granskningar av pull-begäranden är viktiga för att säkerställa att skaparna följer organisationens standarder och metoder för utveckling, kvalitet och efterlevnad.

När du använder pull-begäranden för att sammanfoga ändringar i Power BI-innehåll bör du tänka på följande faktorer.

• Vilka standarder och metoder du ska använda för att utföra din granskning, om några. Du kan till exempel använda regler från Best Practice Analyzer för semantiska modeller.
• Hur du granskar ändringar i rapportmetadata, vilket inte är lätt att läsa och förstå utan att använda verktyg från tredje part.
• Så här hanterar och löser du sammanslagningskonflikter.

Dricks

Se Om pull-begäranden och sammanslagningsstrategier och squashsammanslagning för specifika riktlinjer och rekommendationer om hur du bäst använder pull-begäranden för att underlätta samarbete genom att sammanfoga ändringar i innehåll.

Checklista – När du planerar var du ska lagra filer inkluderar viktiga beslut och åtgärder:

• Välj dina utvecklingsverktyg: Se till att din metod för att utveckla innehåll överensstämmer med hur du ska samarbeta med andra innehållsskapare och använda versionskontroll.
• Välj mellan .pbip- och .pbix-format för modeller och rapporter: Vanligtvis är .pbip-formatet mer fördelaktigt för källkontroll, men självbetjäningsanvändare kan hitta .pbix-filer som är enklare att använda.
• Separat semantisk modell och rapportutveckling: Versionskontrollen är mest effektiv när du hanterar ändringar för olika objekttyper separat. Att separera modell- och rapportutveckling anses vara en bra idé.
• Bestäm hur många arbetsytor du behöver: Att använda separata miljöer är viktigt för att innehållslivscykelhanteringen ska lyckas. Se till att du har förtydligat hur många arbetsytor du behöver och utför lämplig planering på arbetsytenivå.
• Bestäm hur du ska implementera versionskontroll: Bestäm mellan en enklare metod med hjälp av SharePoint eller OneDrive för företag, eller genom att använda Azure DevOps för att underlätta källkontroll.
• Konfigurera fjärrlagringsplatsen: Skapa ett strukturerat utrymme i OneDrive-mappen eller Git-lagringsplatsen där du lagrar innehåll för att spåra och hantera ändringar.
• Om du använder källkontroll konfigurerar du .gitignore- och .gitattributes-filer: Se till att du konfigurerar lagringsplatsen så att du bara spårar meningsfulla ändringar.
• Om du använder källkontroll definierar du förgrenings- och sammanslagningsstrategier: Se till att du definierar tydliga processer för hur du konfigurerar och använder källkontroll för att få bästa möjliga stöd för utveckling. Undvik att överkomplicera processen. Försök i stället att komplettera det nuvarande sättet att arbeta i utvecklingsteamen.

Relaterat innehåll

I nästa artikel i den här serien får du lära dig hur du validerar innehåll som en del av hanteringen av innehållslivscykeln.