Dela via

Användningsscenarier för Power BI: Publicering av företagsinnehåll

  • Artikel

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.

När innehållsskapare samarbetar för att leverera analyslösningar som är viktiga för organisationen måste de säkerställa att innehållet levereras i rätt tid och är tillförlitligt för konsumenterna. Tekniska team hanterar den här utmaningen med hjälp av en process som kallas DevOps. DevOps gör det möjligt för team att automatisera och skala processer genom att införa metoder som förbättrar och påskyndar leveransen.

Kommentar

Datateam som hanterar samma utmaningar kan också träna DataOps. DataOps bygger på DevOps-principer, men DataOps innehåller ytterligare metoder som är specifika för datahantering, till exempel kvalitetssäkring och styrning av data. Vi refererar till DevOps i den här artikeln, men tänk på att de underliggande principerna också kan gälla för DataOps.

Innehållsskapare och konsumenter drar nytta av flera fördelar när de använder DevOps-metoder för att publicera Power BI-innehåll. Följande punkter är en översikt på hög nivå över hur den här processen fungerar.

  1. Utveckla innehåll och checka in arbete till en fjärrlagringsplats: Innehållsskapare utvecklar sin lösning på sin egen dator. De checkar in och sparar sitt arbete på en fjärrlagringsplats med jämna mellanrum under utvecklingen. En fjärrlagringsplats innehåller den senaste versionen av lösningen och den är tillgänglig för hela utvecklingsteamet.
  2. Samarbeta och hantera innehållsändringar med hjälp av versionskontroll: Andra innehållsskapare kan göra ändringar i lösningen genom att skapa en gren. En gren är en kopia av en fjärrlagringsplats. När dessa revisioner är klara och godkända sammanfogas grenen med den senaste versionen av lösningen. Alla revisioner av lösningen spåras. Den här processen kallas versionskontroll (eller källkontroll).
  3. Distribuera och höja upp innehåll med hjälp av pipelines: I användningsscenariot för självbetjäning av innehållspublicering höjs innehållet upp (eller distribueras) via arbetsytor för utveckling, testning och produktion med hjälp av Power BI-distributionspipelines. Power BI-distributionspipelines kan höja upp innehåll till Power BI Premium-arbetsytor manuellt med hjälp av användargränssnittet eller programmatiskt med hjälp av REST-API:erna. Företagsinnehållspublicering (fokus i det här användningsscenariot) höjer däremot upp innehåll med hjälp av Azure Pipelines. Azure Pipelines är en Azure DevOps-tjänst som automatiserar testning, hantering och distribution av innehåll med hjälp av en serie anpassade, programmatiska steg. I scenariot för publicering av företagsinnehåll kan dessa pipelines även kallas kontinuerlig integrering och distributionspipelines (eller CI/CD). Dessa pipelines integrerar ofta och automatiskt ändringar och effektiviserar innehållspublicering.

Viktigt!

Ibland refererar den här artikeln till Power BI Premium eller dess kapacitetsprenumerationer (P SKU:er). Tänk på att Microsoft för närvarande konsoliderar köpalternativ och drar tillbaka Power BI Premium per kapacitets-SKU:er. Nya och befintliga kunder bör överväga att köpa kapacitetsprenumerationer för Infrastrukturresurser (F SKU:er) i stället.

Mer information finns i Viktig uppdatering som kommer till Power BI Premium-licensiering och Vanliga frågor och svar om Power BI Premium.

DevOps stöder en mogen, systematisk metod för innehållshantering och publicering. Det gör det möjligt för innehållsskapare att samarbeta kring lösningar, och det säkerställer en snabb och tillförlitlig leverans av innehåll till konsumenter. När du följer DevOps-metoder kan du dra nytta av effektiva arbetsflöden, färre fel och förbättrade upplevelser för innehållsskapare och innehållskonsumenter.

Du konfigurerar och hanterar DevOps-metoder för din Power BI-lösning med hjälp av Azure DevOps. I företagsscenarier kan du automatisera innehållspublicering med Azure DevOps och Power BI REST-API:er på tre olika sätt.

  • Power BI REST-API:er med Power BI-distributionspipelines: Du kan importera innehåll till arbetsytor för utveckling och använda distributionspipelines för att distribuera innehåll via test- och produktionsarbetsytor. Du styr fortfarande distributionen från Azure DevOps och använder Power BI REST API:er för att hantera distributionspipelines i stället för enskilda innehållsobjekt. Dessutom använder du XMLA-slutpunkten för att distribuera datamodellmetadata i stället för en Power BI Desktop-fil (.pbix) med Azure DevOps. Med dessa metadata kan du spåra ändringar på objektnivå med hjälp av versionskontroll. Även om det är mer robust och enklare att underhålla kräver den här metoden Premium-licensiering och måttlig skriptarbete för att konfigurera innehållsimport och distribution med Power BI REST-API:er. Använd den här metoden när du vill förenkla innehållslivscykelhanteringen med distributionspipelines och du har en Premium-licens. XMLA-slutpunkten och Power BI-distributionspipelines är Premium-funktioner.
  • Power BI REST-API:er: Du kan också importera innehåll till arbetsytor för utveckling, testning och produktion med hjälp av Azure DevOps och endast Power BI REST-API:er. Den här metoden kräver inte Premium-licensiering, men det innebär mycket skriptarbete och installation eftersom distributionen hanteras utanför Power BI. Använd den här metoden när du vill distribuera Power BI-innehåll centralt från Azure DevOps eller när du inte har en Premium-licens. En visuell jämförelse mellan de två första metoderna finns i flödesdiagrammet för versionspipelines.
  • Power BI-automatiseringsverktyg med Power BI-distributionspipelines: Du kan använda Azure DevOps-tillägget för Power BI-automatiseringsverktyg för att hantera distributionspipelines i stället för Power BI REST-API:er. Den här metoden är ett alternativ till det första alternativet, som använder Power BI REST-API:er med Power BI-distributionspipelines. Power BI Automation Tools-tillägget är ett öppen källkod verktyg. Det hjälper dig att hantera och publicera innehåll från Azure DevOps utan att behöva skriva PowerShell-skript. Använd den här metoden när du vill hantera distributionspipelines från Azure DevOps med minimal skriptinsats och du har en Premium-kapacitet.

Den här artikeln fokuserar på det första alternativet, som använder Power BI REST-API:er med Power BI-distributionspipelines. Den beskriver hur du kan använda Azure DevOps för att konfigurera DevOps-metoder. Den beskriver också hur du kan använda Azure Repos för dina fjärranslutna lagringsplatser och automatisera innehållstestning, integrering och leverans med Azure Pipelines. Azure DevOps är inte det enda sättet att konfigurera publicering av företagsinnehåll, men enkel integrering med Power BI gör det till ett bra val.

Kommentar

Det här användningsscenariot är ett av scenarierna för innehållshantering och distribution . I korthet beskrivs inte vissa aspekter som beskrivs i avsnittet om innehållssamarbete och leveransscenarier i den här artikeln. För fullständig täckning, läs dessa artiklar först.

Dricks

Microsoft Fabric tillhandahåller andra alternativ för publicering av företagsinnehåll med hjälp av Fabric Git-integrering. Med Git-integrering kan du länka en Infrastruktur-arbetsyta till en gren på fjärrlagringsplatsen för Azure Repos. Innehåll som sparats i den grenen synkroniseras automatiskt till arbetsytan, som om innehållet publicerades på arbetsytan. Omvänt kan innehållsskapare checka in och skicka ändringar från arbetsytan Infrastruktur till fjärrlagringsplatsen.

Git-integrering kan effektivisera samarbete och innehållspublicering, men det krävs mer planering för hur du ska använda Fabric-arbetsytor och vad din förgreningsstrategi är. Mer information om hur du kan konfigurera och använda Fabric Git-integrering finns i Komma igång med Git-integrering eller Självstudie: Hantering av livscykeln från slutpunkt till slutpunkt.

Scenariodiagram

Följande diagram visar en översikt på hög nivå över de vanligaste användaråtgärderna och Power BI-komponenterna som stöder publicering av företagsinnehåll. Fokus ligger på användningen av Azure DevOps för att hantera och publicera innehåll programmatiskt i stor skala via arbetsytor för utveckling, testning och produktion i Power BI-tjänst.

Diagram visar publicering av företagsinnehåll, vilket handlar om att förbättra samarbetet och hantera innehåll i stor skala med hjälp av Azure DevOps. Objekt i diagrammet beskrivs i tabellen.

Dricks

Vi rekommenderar att du laddar ned scenariodiagrammet om du vill bädda in det i presentationen, dokumentationen eller blogginlägget eller skriva ut det som en väggaffisch. Eftersom det är en SVG-bild (Scalable Vector Graphics) kan du skala upp eller ned den utan någon kvalitetsförlust.

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

Artikel Beskrivning
Objekt 1. Innehållsskapare utvecklar datamodeller med power BI Desktop eller tabellredigeraren och utvecklar rapporter med hjälp av Power BI Desktop. Innehållsskapare sparar sitt arbete på en lokal lagringsplats under utvecklingen.
Objekt 2. Innehållsskapare kan klona en fjärrlagringsplats för att hämta en lokal kopia av innehållet.
Objekt 3. Vissa datakällor kan kräva en lokal datagateway eller VNet-gateway för datauppdatering, som de som finns i ett privat organisationsnätverk.
Objekt 4. Innehållsskapare checkar regelbundet in och push-överför sina ändringar till en fjärrlagringsplats under utvecklingen med hjälp av en Git-klient, till exempel Visual Studio Code. I diagrammet är fjärrlagringsplatsen Azure Repos.
Objekt 5. Andra innehållsskapare använder Azure Repos för att spåra ändringar med versionskontroll. De samarbetar genom att genomföra ändringar i separata grenar.
Objekt 6. Ändringar av innehåll på fjärrlagringsplatsen utlöser Azure Pipelines. En valideringspipeline är den första pipelinen som utlöses. Valideringspipelinen utför automatiserade tester för att verifiera innehåll innan det publiceras.
Objekt 7. Innehåll som skickar valideringspipelinen utlöser en efterföljande bygg-pipeline. Bygg-pipelinen förbereder innehåll för publicering till Power BI-tjänst. Processen fram till denna punkt kallas vanligtvis kontinuerlig integrering (CI).
Objekt 8. Innehållet publiceras och distribueras med hjälp av versionspipelines. Versionspipelines använder antingen Power BI REST-API:er eller arbetsytans XMLA-slutpunkt för att programmatiskt importera innehåll till Power BI-tjänst. Distribution med hjälp av versionspipelines kallas vanligtvis kontinuerlig distribution (CD).
Objekt 9. En versionshanterare styr distributionen för att testa och produktionsarbetsytor med hjälp av ett godkännande av Azure Pipelines-versioner. I publicering av företagsinnehåll planerar och samordnar en versionshanterare vanligtvis innehållsversionen för att testa och produktionsmiljöer. De samordnar och kommunicerar med innehållsskapare, intressenter och användare.
Objekt 10. En versionspipeline publicerar innehåll till utvecklingsarbetsytan eller höjer upp innehåll från utveckling till testarbetsytor eller test till produktionsarbetsytor.
Objekt 11. Innehållsskapare som arbetar på en arbetsyta som har licensläge för infrastrukturkapacitet kan använda Git-integrering. Med Git-integrering kan innehållsskapare arbeta på en privat arbetsyta under utvecklingen. Innehållsskapare synkroniserar en fjärrgren (vanligtvis en specifik funktionsgren eller en bugggren) från Azure Repos till deras privata arbetsyta. Innehållsändringar synkroniseras mellan fjärrgrenen i Azure Repos och arbetsytan. I det här scenariot behöver innehållsskapare inte använda Azure Pipelines för att publicera innehåll. Innehållsskapare kan också regelbundet checka in och skicka ändringar från arbetsytan efter publicering. När de är klara kan innehållsskapare göra en pull-begäran (PR) för att sammanfoga sina ändringar till huvudgrenen.
Objekt 12. När du använder Git-integrering synkroniseras utvecklingsarbetsytan med huvudgrenen för att hämta de senaste versionerna av innehåll. Det här innehållet innehåller alla ändringar från pull-begäranden som en versionshanterare granskar, godkänner och sammanfogar.
Objekt 13. Arbetsytor är inställda på Infrastrukturkapacitet, Premium-kapacitet, Premium per användare eller Inbäddatlicensläge för att tillåta användning av Power BI-distributionspipelines och XMLA-slutpunkten för läsning/skrivning.
Objekt 14. En administratör för distributionspipelinen konfigurerar Power BI-distributionspipelinen med tre steg: utveckling, testning och produktion. Varje fas justeras till en separat arbetsyta i Power BI-tjänst. Distributionsinställningar och åtkomst anges för distributionspipelinen.
Objekt 15. Utvecklingsarbetsytan innehåller de senaste versionerna av innehåll, inklusive alla godkända och sammanfogade ändringar. När en versionspipeline har godkänts distribueras innehåll från utvecklingen till testarbetsytan.
Objekt 16. Granskare på testarbetsytan utför testning och kvalitetssäkring av innehåll. När en versionspipeline har godkänts distribueras innehåll från testet till produktionsarbetsytan. När du använder Git-integrering med distributionspipelines synkroniseras inte testarbetsytan med någon gren.
Objekt 17. När distributionspipelinen har slutfört distributionen utför innehållsskapare manuellt aktiviteter efter distributionen. Aktiviteter kan vara att konfigurera schemalagd datauppdatering eller uppdatera en Power BI-app för produktionsarbetsytan. När du använder Git-integrering med distributionspipelines synkroniseras inte produktionsarbetsytan med någon gren.
Objekt 18. Innehållsvisningsprogram får åtkomst till innehållet med hjälp av produktionsarbetsytan eller en Power BI-app.

Dricks

Vi rekommenderar att du även granskar användningsscenarier för självbetjäningsinnehållspublicering och avancerad datamodellhantering . Användningsscenariot för publicering av företagsinnehåll bygger på begrepp som dessa scenarier introducerar.

Huvudpunkter

Följande är några viktiga punkter att betona om scenariot för publicering av företagsinnehåll.

Versionskontroll

Det är viktigt att spåra ändringar under innehållslivscykeln för att säkerställa en stabil och konsekvent leverans av innehåll till konsumenterna. I det här användningsscenariot hanterar innehållsskapare och ägare innehållsändringar på en fjärrlagringsplats 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 ger bättre samarbete och effektiv hantering av versionshistorik. Versionskontrollen har fördelar för innehållsskapare, inklusive möjligheten att återställa eller sammanfoga ändringar.

Innehållsskapare utvecklar vanligtvis datamodeller i tabellredigeraren för bättre versionskontroll. Till skillnad från en datamodell som du utvecklar i Power BI Desktop sparas en datamodell som utvecklats i tabellredigeraren i metadataformat som kan läsas av människor. Det här formatet aktiverar versionskontroll på objektnivå för datamodeller. Du bör använda versionskontroll på objektnivå när du samarbetar med flera personer i samma datamodell. Mer information finns i användningsscenariot för hantering av avancerade datamodeller. Det går inte att se ändringar som du har gjort i en Power BI Desktop-fil (.pbix), till exempel rapportdefinitionen eller datamodellen. Du kan till exempel inte spåra ändringar på en rapportsida, till exempel de visuella objekt som används, deras positioner och deras fältmappningar eller formatering.

Innehållsskapare lagrar datamodellmetadatafiler och .pbix-filer på en central fjärrlagringsplats, till exempel Azure Repos. 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 avancerade alternativ för att spåra och hantera ändringar. Den här metoden skiljer sig från den metod som beskrivs i användningsscenariot för självbetjäningsinnehållspublicering , där skaparen använder OneDrive-lagring med versionsspårning. Det är viktigt att ha en väldokumenterad, dokumenterad lagringsplats eftersom den utgör grunden för allt innehåll och allt samarbete.

Här följer några viktiga överväganden som hjälper dig att konfigurera en fjärrlagringsplats för versionskontroll.

  • Omfång: Definiera lagringsplatsens omfång tydligt. Helst är lagringsplatsens omfång identiskt 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 lagringsplatsen med hjälp av en liknande behörighetsmodell som du har konfigurerat för dina behörigheter för distributionspipelinen och arbetsyteroller. Innehållsskapare behöver åtkomst till lagringsplatsen.
  • Dokumentation: Lägg till textfiler på lagringsplatsen för att dokumentera dess syfte, ägarskap, åtkomst och definierade processer. Dokumentationen kan till exempel beskriva hur ändringar ska mellanlagras och genomföras.
  • Verktyg: För att checka in och skicka ändringar till en fjärrlagringsplats behöver innehållsskapare en Git-klient som Visual Studio eller Visual Studio Code. Git är ett distribuerat versionskontrollsystem som spårar ändringar i dina filer. Mer information om grunderna i Git finns i Vad är Git?.

Kommentar

Överväg att använda Git Large File Storage (LFS) om du planerar att checka in Power BI Desktop-filer (.pbix). Git LFS innehåller avancerade alternativ för att hantera filer där ändringar inte visas (oundvändbara filer), till exempel en .pbix-fil. Du kan till exempel använda fillåsning för att förhindra samtidiga ändringar i en Power BI-rapport under utvecklingen. Git LFS har dock en egen klient och konfiguration.

Samarbete med Azure DevOps

När en lösning ökar i omfattning och komplexitet kan det bli nödvändigt för flera innehållsskapare och ägare att arbeta i samarbete. Innehållsskapare och ägare kommunicerar och samarbetar i en central, organiserad hubb med hjälp av Azure DevOps.

Om du vill samarbeta och kommunicera i Azure DevOps använder du stödtjänster.

  • Azure Boards: Innehållsägare använder tavlor för att spåra arbetsobjekt. Arbetsobjekt tilldelas var och en till en enskild utvecklare i teamet, och de beskriver problem, buggar eller funktioner i lösningen och motsvarande intressenter.
  • Azure Wiki: Innehållsskapare delar information med sitt team för att förstå och bidra till lösningen.
  • Azure Repos: Innehållsskapare spårar ändringar i fjärrlagringsplatsen och sammanfogar dem till en enda lösning.
  • Azure Pipelines: Pipelineägare konfigurerar programmatisk logik för att distribuera lösningen, antingen automatiskt eller på begäran.

Samarbetsflödesdiagram

Följande diagram visar en översikt på hög nivå över ett exempel på hur Azure DevOps möjliggör samarbete i scenariot för publicering av företagsinnehåll. Fokus i det här diagrammet ligger på användningen av Azure DevOps för att skapa en strukturerad och dokumenterad innehållspubliceringsprocess.

Diagram enligt beskrivningen i ovanstående stycke. Objekt i diagrammet beskrivs i tabellen nedan.

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

Artikel Beskrivning
Objekt 1. 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.
Objekt 2. Innehållsskapare checkar in sina ändringar på en lokal lagringsplats under utvecklingen.
Objekt 3. 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.
Objekt 4. Innehållsskapare genomför regelbundet sina ändringar. När det är klart publicerar innehållsskapare sin gren till fjärrlagringsplatsen.
Objekt 5. 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.
Objekt 6. Innehållsskapare och innehållsägare dokumenterar lösningen och dess processer i en Azure Wiki, som är tillgänglig för hela utvecklingsteamet.
Objekt 7. När det är klart öppnar innehållsskapare en pull-begäran för att sammanfoga funktionsgrenen till huvudgrenen.
Objekt 8. 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.
Objekt 9. 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.
Objekt 10. 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.
Objekt 11. 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.
Objekt 12. 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.
Objekt 13. 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.
Objekt 14. 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.

För att utveckla kan innehållsskapare samarbeta med hjälp av en förgreningsstrategi. En förgreningsstrategi är hur innehållsskapare skapar, använder och sammanfogar grenar för att effektivt göra och hantera innehållsändringar. Enskilda innehållsskapare arbetar 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 incheckningsmeddelande. Ett incheckningsmeddelande beskriver de ändringar som gjorts i incheckningen.

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.

Samarbetsrekommendationer

Vi rekommenderar att du definierar en strukturerad process för hur innehållsskapare ska samarbeta. Se till att du fastställer:

  • Hur arbetet är begränsat och hur grenar skapas, namnges och används.
  • Hur författare grupperar ändringar och beskriver dem med incheckningsmeddelanden.
  • Vem ansvarar för att granska och godkänna pull-begäranden.
  • Så här löses sammanslagningskonflikter.
  • Hur ändringar som görs i olika grenar sammanfogas till en enda gren.
  • Hur innehåll testas och vem som utför testning innan innehåll distribueras.
  • Hur och när ändringar distribueras till arbetsytor för utveckling, testning och produktion.
  • Hur och när du distribuerar ändringar eller versioner av lösningen bör återställas.

Viktigt!

Värdet som tillhandahålls av DevOps är direkt proportionellt mot efterlevnaden av de processer som definierar dess användning.

Ett lyckat samarbete beror på en väldefinierad process. Det är viktigt att tydligt beskriva och dokumentera arbetsflödet för utveckling från slutpunkt till slutpunkt. Se till att de valda strategierna och processerna överensstämmer med befintliga metoder i ditt team, och om inte, hur du hanterar ändringar. Se dessutom till att processerna är tydliga och kommunicerar med alla teammedlemmar och intressenter. Se till att teammedlemmar och intressenter som är nya i processerna utbildas i hur de ska implementeras och att de uppskattar värdet av en lyckad DevOps-implementering.

Power BI REST-API:er

Du utvecklar programmeringslogik för att importera och distribuera innehåll från Azure DevOps med hjälp av Power BI REST API:er. Du importerar Power BI-filer (.pbix) till en arbetsyta med hjälp av en importåtgärd. Du använder en pipelineåtgärd för att distribuera innehåll eller allt innehåll för att testa eller produktionsarbetsytor med hjälp av Power BI-distributionspipelines. Den programmatiska logiken definieras i Azure Pipelines.

Vi rekommenderar att du använder tjänstens huvudnamn för att anropa Power BI REST-API:er i dina pipelines. Tjänstens huvudnamn är avsett för obevakade, automatiserade aktiviteter och förlitar sig inte på användarautentiseringsuppgifter. Vissa objekt och aktiviteter stöds dock inte av Power BI REST-API:er eller när du använder ett huvudnamn för tjänsten, till exempel dataflöden.

När du använder tjänstens huvudnamn måste du noggrant hantera behörigheter. Målet bör vara att följa principen om lägsta behörighet. Du bör ange tillräckliga behörigheter för tjänstens huvudnamn utan överetableringsbehörigheter. Använd Azure Key Vault eller en annan tjänst som lagrar tjänstens huvudnamnshemligheter och autentiseringsuppgifter på ett säkert sätt.

Varning

Om du har en datamodell som sparas som ett metadataformat som kan läsas av människor kan den inte publiceras med hjälp av Power BI REST-API:er. I stället måste du publicera den med hjälp av XMLA-slutpunkten. Du kan publicera metadatafiler med hjälp av verktyg från tredje part, till exempel kommandoradsgränssnittet för tabellredigeraren (CLI). Du kan också publicera metadatafiler programmatiskt med hjälp av din egen anpassade .NET-utveckling. Det krävs mer arbete för att utveckla en anpassad lösning, eftersom du måste använda TOM-tillägget (Microsoft Tabular Object Model) för AMO-klientbiblioteken (Analysis Management Object).

Azure-pipelines

Azure Pipelines automatiserar programmatiskt testning, hantering och distribution av innehåll. När en pipeline körs körs stegen i pipelinen automatiskt. Pipelineägare kan anpassa sina utlösare, steg och funktioner för att uppfylla distributionsbehoven. Därför varierar antalet och typerna av pipelines beroende på lösningskraven. En Azure Pipeline kan till exempel köra automatiserade tester eller ändra datamodellparametrar före en distribution.

Det finns tre typer av Azure Pipelines som du kan konfigurera för att testa, hantera och distribuera din Power BI-lösning:

  • Valideringspipelines.
  • Skapa pipelines.
  • Versionspipelines.

Kommentar

Det är inte nödvändigt att ha alla tre pipelines i publiceringslösningen. Beroende på ditt arbetsflöde och dina behov kan du konfigurera en eller flera av varianterna av pipelines som beskrivs i den här artikeln för att automatisera innehållspublikationen. Den här möjligheten att anpassa pipelines är en fördel med Azure Pipelines jämfört med de inbyggda Power BI-distributionspipelines. Du behöver till exempel inte ha någon valideringspipeline. du kan bara använda bygg- och versionspipelines.

Valideringspipelines

Valideringspipelines utför grundläggande kvalitetskontroller av datamodeller innan de publiceras till en utvecklingsarbetsyta. Normalt utlöser ändringar i en gren av fjärrlagringsplatsen pipelinen för att verifiera ändringarna med automatiserad testning.

Exempel på automatiserad testning är genomsökning av datamodellen efter regelöverträdelser med bästa praxis med hjälp av BPA (Best Practice Analyzer ) eller genom att köra DAX-frågor mot en publicerad semantisk modell. Resultatet av dessa tester lagras sedan på fjärrlagringsplatsen i dokumentations- och granskningssyfte. Datamodeller som inte kan valideras bör inte publiceras. I stället bör pipelinen meddela innehållsskaparna om problemen.

Skapa pipelines

Bygg pipelines förbereder datamodeller för publicering till Power BI-tjänst. Dessa pipelines kombinerar serialiserade modellmetadata till en enda fil som senare publiceras av en versionspipeline (beskrivs i diagrammet över versionspipelines). En byggpipeline kan också göra andra ändringar i metadata, till exempel ändra parametervärden. Byggpipelines producerar distributionsartefakter som består av datamodellmetadata (för datamodeller) och Power BI Desktop-filer (.pbix) som är redo för publicering till Power BI-tjänst.

Versionspipelines

Versionspipelines publicerar eller distribuerar innehåll. En publiceringslösning innehåller vanligtvis flera versionspipelines, beroende på målmiljön.

  • Utvecklingsversionspipeline: Den här första pipelinen utlöses automatiskt. Den publicerar innehåll till en utvecklingsarbetsyta när bygg- och valideringspipelines har slutförts.
  • Test- och produktionsversionspipelines: Dessa pipelines utlöses inte automatiskt. I stället utlöses de på begäran eller när de godkänns. Test- och produktionsversionspipelines distribuerar innehåll till en test- eller produktionsarbetsyta efter godkännande av versionen. Versionsgodkännanden säkerställer att innehållet inte distribueras automatiskt till ett test- eller produktionssteg innan det är klart. Dessa godkännanden tillhandahålls av versionshanterare som ansvarar för planering och samordning av innehållslansering för att testa och produktionsmiljöer.

Det finns två olika metoder för att publicera innehåll med test- och versionspipelines. Antingen höjer de upp innehåll med hjälp av en Power BI-distributionspipeline eller publicerar innehåll till Power BI-tjänst från Azure DevOps.

Följande diagram visar den första metoden. I den här metoden samordnar versionspipelines innehållsdistributionen för att testa och produktionsarbetsytor med hjälp av Power BI-distributionspipelines. Innehållet höjs upp via arbetsytor för utveckling, testning och produktion i Power BI. Även om den här metoden är mer robust och enklare att underhålla krävs Premium-licensiering.

Diagrammet visar den första metoden enligt beskrivningen i ovanstående stycke. Objekt i diagrammet beskrivs i tabellen nedan.

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

Artikel Beskrivning
Objekt 1. I den första metoden publicerar versionspipelines innehåll med hjälp av XMLA-slutpunkten och Power BI REST-API:erna med Power BI-distributionspipelines. Innehållet publiceras och befordras sedan via arbetsytor för utveckling, testning och produktion. Power BI-distributionspipelines och XMLA-slutpunkten för läsning/skrivning är Premium-funktioner.
Objekt 2. Antingen utlöser en lyckad grensammanslagning eller slutförande av en överordnad pipeline bygg-pipelinen. Bygg-pipelinen förbereder sedan innehåll för publicering och utlöser pipelinen för utvecklingsversionen.
Objekt 3. Pipelinen för utvecklingsversionen publicerar innehåll på utvecklingsarbetsytan med hjälp av XMLA-slutpunkten (för datamodellmetadata) eller Power BI REST-API:er (för Power BI Desktop-filer, som kan innehålla datamodeller och rapporter). Utvecklingspipelinen använder kommandoradsgränssnittet för tabellredigeraren (CLI) för att distribuera datamodellmetadata med hjälp av XMLA-slutpunkten.
Objekt 4. Ett versionsgodkännande eller en utlösare på begäran aktiverar testversionspipelinen.
Objekt 5. Testversionspipelinen distribuerar innehåll med hjälp av power BI REST API-distributionsåtgärder, som kör Power BI-distributionspipelinen.
Objekt 6. Power BI-distributionspipelinen befordrar innehåll från arbetsytan för utveckling till testarbetsytan. Efter distributionen utför versionspipelinen aktiviteter efter distributionen med hjälp av Power BI REST API:er (visas inte i diagrammet).
Objekt 7. Ett versionsgodkännande eller en utlösare på begäran aktiverar pipelinen för produktionsversionen.
Objekt 8. Pipelinen för produktionsversionen distribuerar innehåll med hjälp av power BI REST API-distributionsåtgärder som kör Power BI-distributionspipelinen.
Objekt 9. Power BI-distributionspipelinen befordrar innehåll från testarbetsytan till produktionsarbetsytan. Efter distributionen utför versionspipelinen aktiviteter efter distributionen med hjälp av Power BI REST API:er (visas inte i diagrammet).

Följande diagram visar den andra metoden. Den här metoden använder inte distributionspipelines. I stället använder den versionspipelines för att publicera innehåll för att testa och produktionsarbetsytor från Azure DevOps. Den här andra metoden kräver inte Premium-licensiering när du endast publicerar Power BI Desktop-filer med Power BI REST-API:er. Det innebär mer konfiguration och komplexitet eftersom du måste hantera distribution utanför Power BI. Utvecklingsteam som redan använder DevOps för datalösningar utanför Power BI kanske är mer bekanta med den här metoden. Utvecklingsteam som använder den här metoden kan konsolidera distributionen av datalösningar i Azure DevOps.

Diagrammet visar den andra metoden enligt beskrivningen i ovanstående stycke. Objekt i diagrammet beskrivs i tabellen nedan.

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

Artikel Beskrivning
Objekt 1. I den andra metoden publicerar versionspipelines innehåll med hjälp av XMLA-slutpunkten och endast Power BI REST-API:erna. Innehållet publiceras till arbetsytor för utveckling, testning och produktion.
Objekt 2. Antingen utlöser en lyckad grensammanslagning eller slutförande av en överordnad pipeline bygg-pipelinen. Bygg-pipelinen förbereder sedan innehåll för publicering och utlöser pipelinen för utvecklingsversionen.
Objekt 3. Pipelinen för utvecklingsversionen publicerar innehåll på utvecklingsarbetsytan med hjälp av XMLA-slutpunkten (för datamodellmetadata) eller Power BI REST-API:er (för Power BI Desktop-filer, som kan innehålla datamodeller och rapporter). Utvecklingspipelinen använder kommandoradsgränssnittet för tabellredigeraren (CLI) för att distribuera datamodellmetadata med hjälp av XMLA-slutpunkten.
Objekt 4. Ett versionsgodkännande eller en utlösare på begäran aktiverar testversionspipelinen.
Objekt 5. Pipelinen för utvecklingsversionen publicerar innehåll på testarbetsytan med hjälp av XMLA-slutpunkten (för datamodellmetadata) eller Power BI REST-API:er (för Power BI Desktop-filer, som kan innehålla datamodeller och rapporter). Utvecklingspipelinen använder kommandoradsgränssnittet för tabellredigeraren (CLI) för att distribuera datamodellmetadata med hjälp av XMLA-slutpunkten. Efter distributionen utför versionspipelinen aktiviteter efter distributionen med hjälp av Power BI REST API:er (visas inte i diagrammet).
Objekt 6. Ett versionsgodkännande eller en utlösare på begäran aktiverar pipelinen för produktionsversionen.
Objekt 7. Pipelinen för utvecklingsversionen publicerar innehåll till produktionsarbetsytan med hjälp av XMLA-slutpunkten (för datamodellmetadata) eller Power BI REST-API:er (för Power BI Desktop-filer, som kan innehålla datamodeller och rapporter). Utvecklingspipelinen använder kommandoradsgränssnittet för tabellredigeraren (CLI) för att distribuera datamodellmetadata med hjälp av XMLA-slutpunkten. Efter distributionen utför versionspipelinen aktiviteter efter distributionen med hjälp av Power BI REST API:er (visas inte i diagrammet).

Versionspipelines bör hantera aktiviteter efter distributionen. Dessa aktiviteter kan omfatta att ange autentiseringsuppgifter för semantisk modell eller uppdatera Power BI-appen för test- och produktionsarbetsytor. Vi rekommenderar att du konfigurerar meddelanden för att informera relevanta personer om distributionsaktiviteter.

Dricks

Med hjälp av en lagringsplats för versionskontroll kan innehållsskapare skapa en återställningsprocess. Återställningsprocessen kan vända den senaste distributionen genom att återställa den tidigare versionen. Överväg att skapa en separat uppsättning Azure Pipelines som du kan utlösa för att återställa produktionsändringar. Tänk noga på vilka processer och godkännanden som krävs för att initiera en återställning. Kontrollera att dessa processer är dokumenterade.

Power BI-distributionspipelines

En Power BI-distributionspipeline består av tre steg: utveckling, test och produktion. Du tilldelar en enda Power BI-arbetsyta till varje steg i distributionspipelinen. När en distribution sker befordrar distributionspipelinen Power BI-objekt från en arbetsyta till en annan.

En Azure Pipelines-versionspipeline använder Power BI REST API:er för att distribuera innehåll med hjälp av en Power BI-distributionspipeline. Åtkomst till både arbetsytan och distributionspipelinen krävs för de användare som utför en distribution. Vi rekommenderar att du planerar distributionspipelineåtkomst så att pipelineanvändare kan visa distributionshistorik och jämföra innehåll.

Dricks

När du separerar dataarbetsytor från rapporteringsarbetsytor bör du överväga att använda Azure Pipelines för att samordna innehållspublicering med flera Power BI-distributionspipelines. Semantisk modell distribueras först och sedan uppdateras de. Slutligen distribueras rapporter. Den här metoden hjälper dig att förenkla distributionen.

Premiumlicensiering

Power BI-distributionspipelines och XMLA-slutpunkten för läsning/skrivning är Premium-funktioner. Dessa funktioner är tillgängliga med Power BI Premium-kapacitet och Power BI Premium per användare (PPU).

PPU är ett kostnadseffektivt sätt att hantera publicering av företagsinnehåll för utveckling och testning av arbetsytor, som vanligtvis har få användare. Den här metoden har den extra fördelen att isolera utvecklings- och testarbetsbelastningar från produktionsarbetsbelastningar.

Kommentar

Du kan fortfarande konfigurera företagsinnehållspublicering utan en Premium-licens, enligt beskrivningen i den andra metoden i avsnittet versionspipeline . I den andra metoden använder du Azure Pipelines för att hantera distributionen av Power BI Desktop-filer till arbetsytor för utveckling, testning och produktion. Du kan dock inte distribuera modellmetadata med hjälp av XMLA-slutpunkten eftersom det inte går att publicera en semantisk modell för metadataformat med Power BI REST-API:er. Dessutom går det inte att höja upp innehåll via miljöer med distributionspipelines utan en Premium-licens.

Gateway-konfiguration

Normalt krävs en datagateway vid åtkomst till datakällor som finns i det privata organisationsnätverket eller ett virtuellt nätverk. De två syftena med en gateway är att uppdatera importerade data och visa en rapport som frågar en live-anslutning eller DirectQuery-semantisk modell (visas inte i scenariodiagrammet).

När du arbetar med flera miljöer är det vanligt att konfigurera utvecklings-, test- och produktionsanslutningar till olika källsystem. I det här fallet använder du datakällans regler och parameterregler för att hantera värden som skiljer sig mellan miljöer. Du kan använda Azure Pipelines för att hantera gatewayer med hjälp av gatewayåtgärderna för Power BI REST-API:er.

Kommentar

En centraliserad datagateway i standardläge rekommenderas starkt för gatewayer i personligt läge. I standardläge stöder datagatewayen live-anslutning och DirectQuery-åtgärder (utöver schemalagda datauppdateringsåtgärder).

Systemtillsyn

Aktivitetsloggen registrerar händelser som inträffar i Power BI-tjänst. Power BI-administratörer kan använda aktivitetsloggen för att granska distributionsaktiviteter.

Du kan använda API:er för genomsökning av Power BI-metadata för att skapa en klientinventering. API-resultaten är användbara för att verifiera vilka objekt som har distribuerats till varje arbetsyta, för att kontrollera ursprunget och för att verifiera säkerhetsinställningarna.

Det finns också en granskningslogg i Azure DevOps, som ligger utanför Power BI-tjänst. Azure DevOps-administratörer kan använda granskningsloggen för att granska aktiviteter i fjärranslutna lagringsplatser och pipelines.

Relaterat innehåll

Andra användbara scenarier som hjälper dig med beslut om Power BI-implementering finns i artikeln Om Power BI-användningsscenarier .