Power BI-forbrugsscenarier: Udgivelse af virksomhedsindhold

Bemærk

Denne artikel er en del af power BI-implementeringsplanlægningsserierne. I denne serie fokuseres der primært på Power BI-oplevelsen i Microsoft Fabric. Du kan få en introduktion til serien under Planlægning af implementering af Power BI.

Når indholdsoprettere samarbejder om at levere analytiske løsninger, der er vigtige for organisationen, skal de sikre rettidig og pålidelig levering af indhold til forbrugere. Tekniske teams håndterer denne udfordring ved hjælp af en proces, der kaldes DevOps. DevOps gør det muligt for teams at automatisere og skalere processer ved at indføre fremgangsmåder, der forbedrer og fremskynder leveringen.

Bemærk

Datateams, der håndterer de samme udfordringer, kan også øve sig i DataOps. DataOps bygger på DevOps-principper, men DataOps indeholder yderligere fremgangsmåder, der er specifikke for datastyring, f.eks. kvalitetssikring og styring af data. Vi henviser til DevOps i denne artikel, men vær opmærksom på, at de underliggende principper også kan gælde for DataOps.

Indholdsoprettere og forbrugere drager fordel af flere fordele, når de bruger DevOps-praksisser til at publicere Power BI-indhold. Følgende punkter er en overordnet oversigt over, hvordan denne proces fungerer.

1. Udvikl indhold, og send arbejde til et eksternt lager: Indholdsoprettere udvikler deres løsning på deres egen computer. De sender og gemmer deres arbejde i et eksternt lager med jævne mellemrum under udviklingen. Et fjernlager indeholder den nyeste version af løsningen, og det er tilgængeligt for hele udviklingsteamet.
2. Samarbejd og administrer indholdsændringer ved hjælp af versionsstyring: Andre indholdsoprettere kan foretage ændringer af løsningen ved at oprette en forgrening. En forgrening er en kopi af et fjernlager. Når disse ændringer er klar og godkendt, flettes forgreningen med den nyeste version af løsningen. Alle ændringer af løsningen spores. Denne proces kaldes versionsstyring (eller kildekontrolelement).
3. Udrul og fremhæv indhold ved hjælp af pipelines: I selvbetjent indholdspublicering forbrugsscenarie overføres indhold (eller udrulles) via udviklings-, test- og produktionsarbejdsområder ved hjælp af Power BI-udrulningspipelines. Power BI-udrulningspipelines kan hæve indhold til Power BI Premium-arbejdsområder manuelt ved hjælp af brugergrænsefladen eller via programmering ved hjælp af REST API'erne. I modsætning hertil fremhæver publicering af virksomhedsindhold (fokus i dette forbrugsscenarie) indhold ved hjælp af Azure Pipelines. Azure Pipelines er en Azure DevOps-tjeneste, der automatiserer test, administration og udrulning af indhold ved hjælp af en række brugerdefinerede, programmatiske trin. I brugsscenariet for udgivelse af virksomhedsindhold kan disse pipelines også kaldes for kontinuerlig integration og udrulningspipelines (eller CI/CD). Disse pipelines integrerer ofte og automatisk ændringer og strømliner indholdspublicering.

Vigtigt

Denne artikel henviser til tider Power BI Premium eller dens kapacitetsabonnementer (P-SKU'er). Vær opmærksom på, at Microsoft i øjeblikket konsoliderer købsmuligheder og udfaser Power BI Premium pr. kapacitets-SKU'er. Nye og eksisterende kunder bør overveje at købe Fabric-kapacitetsabonnementer (F SKU'er) i stedet.

Du kan få flere oplysninger under Vigtige opdateringer, der kommer til Power BI Premium-licenser og Ofte stillede spørgsmål om Power BI Premium.

DevOps understøtter en moden, systematisk tilgang til indholdsstyring og -publikation. Det gør det muligt for indholdsoprettere at samarbejde om løsninger, og det sikrer hurtig og pålidelig levering af indhold til forbrugere. Når du overholder DevOps-praksisser, kan du drage fordel af strømlinede arbejdsprocesser, færre fejl og forbedrede oplevelser for indholdsforfattere og indholdsforbrugere.

Du kan konfigurere og administrere DevOps-fremgangsmåder for din Power BI-løsning ved hjælp af Azure DevOps. I virksomhedsscenarier kan du automatisere indholdspublikation med Azure DevOps og REST API'erne til Power BI på tre forskellige måder.

• REST API'er til Power BI med Power BI-udrulningspipelines: Du kan importere indhold til udviklingsarbejdsområder og bruge udrulningspipelines til at udrulle indhold via test- og produktionsarbejdsområder. Du styrer stadig udrulningen fra Azure DevOps og bruger REST API'erne til Power BI til at administrere udrulningspipelines i stedet for individuelle indholdselementer. Derudover kan du bruge XMLA-slutpunktet til at installere metadata for datamodeller i stedet for en Power BI Desktop-fil (.pbix) med Azure DevOps. Disse metadata giver dig mulighed for at spore ændringer på objektniveau ved hjælp af versionsstyring. Selvom denne fremgangsmåde er mere robust og nemmere at vedligeholde, kræver den premiumlicensering og moderat scripting for at konfigurere indholdsimport og -udrulning med REST API'erne til Power BI. Brug denne fremgangsmåde, når du vil forenkle administration af indholdslivscyklus med udrulningspipelines, og du har en Premium-licens. XMLA-slutpunktet og Power BI-udrulningspipelines er Premium-funktioner.
• REST API'er til Power BI: Du kan også importere indhold til udviklings-, test- og produktionsarbejdsområder ved hjælp af Azure DevOps og kun REST API'erne til Power BI. Denne fremgangsmåde kræver ikke Premium-licenser, men det kræver en stor scriptingindsats og konfiguration, fordi udrulningen administreres uden for Power BI. Brug denne fremgangsmåde, når du vil installere Power BI-indhold centralt fra Azure DevOps, eller når du ikke har en Premium-licens. Hvis du vil have en visuel sammenligning mellem de første to tilgange, skal du se flowdiagrammet med tilgange til udgivelsespipeline.
• Power BI-automatiseringsværktøjer med Power BI-udrulningspipelines: Du kan bruge Power BI-automatiseringsværktøjer Udvidelsen Azure DevOps til at administrere udrulningspipelines i stedet for REST API'erne til Power BI. Denne fremgangsmåde er et alternativ til den første indstilling, som bruger REST API'er til Power BI med Power BI-udrulningspipelines. Udvidelsen af Power BI-automatiseringsværktøjer er et åben kildekode værktøj. Det hjælper dig med at administrere og publicere indhold fra Azure DevOps uden at skulle skrive PowerShell-scripts. Brug denne fremgangsmåde, når du vil administrere udrulningspipelines fra Azure DevOps med en minimal scriptingindsats, og du har en Premium-kapacitet.

I denne artikel fokuseres der på den første indstilling, som bruger REST API'er til Power BI med Power BI-udrulningspipelines. Den beskriver, hvordan du kan bruge Azure DevOps til at konfigurere DevOps-fremgangsmåder. Den beskriver også, hvordan du kan bruge Azure Repos til dine fjernlagre og automatisere test af indhold, integration og levering med Azure Pipelines. Azure DevOps er ikke den eneste måde at konfigurere publicering af virksomhedsindhold på, men enkel integration med Power BI gør det til et godt valg.

Bemærk

Dette forbrugsscenarie er et af scenarierne til administration og installation af indhold. Nogle aspekter, der er beskrevet i emnet om indholdssamarbejde og leveringsscenarier , beskrives ikke kort i denne artikel. Du kan få fuld dækning ved at læse disse artikler først.

Tip

Microsoft Fabric indeholder andre muligheder for udgivelse af virksomhedsindhold ved hjælp af Fabric Git-integration. Med Git-integration kan du knytte et Fabric-arbejdsområde til en forgrening i dit Azure Repos-fjernlager. Indhold, der er gemt i den pågældende forgrening, synkroniseres automatisk med arbejdsområdet, som om indholdet blev publiceret i arbejdsområdet. Omvendt kan indholdsoprettere bekræfte og overføre ændringer fra Fabric-arbejdsområdet til fjernlageret.

Git-integration kan strømline samarbejde og udgivelse af indhold, men det kræver mere planlægning af, hvordan du bruger Fabric-arbejdsområder, og hvad din forgreningsstrategi er. Du kan få flere oplysninger om, hvordan du konfigurerer og bruger Fabric Git-integration, under Kom i gang med Git-integration eller Selvstudium: End to end-livscyklusstyring.

Scenariediagram

I følgende diagram vises en oversigt på højt niveau over de mest almindelige brugerhandlinger og Power BI-komponenter, der understøtter publicering af virksomhedsindhold. Fokus er på brugen af Azure DevOps til at administrere og publicere indhold programmatisk i stor skala via udviklings-, test- og produktionsarbejdsområder i Power BI-tjeneste.

Tip

Vi opfordrer dig til at downloade scenariediagrammet , hvis du vil integrere det i din præsentation, dokumentation eller dit blogindlæg – eller udskrive det som en vægplakat. Da det er et SVG-billede (Scalable Vector Graphics), kan du skalere det op eller ned uden tab af kvalitet.

Scenariediagrammet viser følgende brugerhandlinger, processer og funktioner.

Punkt	Beskrivelse
	Indholdsoprettere udvikler datamodeller ved hjælp af Power BI Desktop eller Tabeleditor, og de udvikler rapporter ved hjælp af Power BI Desktop. Indholdsforfattere gemmer deres arbejde i et lokalt lager under udvikling.
	Indholdsoprettere kan klone et fjernlager for at få en lokal kopi af det pågældende indhold.
	Nogle datakilder kan kræve en datagateway i det lokale miljø eller en VNet-gateway til opdatering af data, f.eks. dem, der er placeret i et privat organisationsnetværk.
	Indholdsoprettere sender og sender jævnligt deres ændringer til et fjernlager under udvikling ved hjælp af en Git-klient, f.eks. Visual Studio Code. I diagrammet er fjernlageret Azure Repos.
	Andre oprettere af indhold bruger Azure Repos til at spore ændringer med versionsstyring. De samarbejder ved at udføre ændringer i separate forgreninger.
	Ændringer af indhold i fjernlageret udløser Azure Pipelines. En valideringspipeline er den første pipeline, der udløses. Valideringspipelinen udfører automatiserede test for at validere indhold, før det udgives.
	Indhold, der overfører valideringspipelinen, udløser en efterfølgende buildpipeline. Buildpipelinen forbereder indhold til publicering på Power BI-tjeneste. Processen indtil nu kaldes typisk for kontinuerlig integration (CI).
	Indhold publiceres og installeres ved hjælp af udgivelsespipelines. Udgivelsespipelines bruger enten Power BI REST API'er eller XMLA-slutpunktet for arbejdsområdet til programmeringsmæssigt at importere indhold til Power BI-tjeneste. Udrulning ved hjælp af udgivelsespipelines kaldes typisk for kontinuerlig udrulning (CD).
	En release manager styrer udrulningen for at teste og producere arbejdsområder ved hjælp af en godkendelse af en Udgivelse af Azure Pipelines. I udgivelse af virksomhedsindhold planlægger og koordinerer en udgivelseschef typisk indholdsudgivelsen til test- og produktionsmiljøer. De koordinerer og kommunikerer med indholdsforfattere, interessenter og brugere.
	En udgivelsespipeline publicerer indhold til udviklingsarbejdsområdet eller fremhæver indhold fra udvikling til testarbejdsområder eller test til produktionsarbejdsområder.
	Indholdsforfattere, der arbejder i et arbejdsområde med Fabric-kapacitetslicenstilstand , kan bruge Git-integration. Med Git-integration kan indholdsoprettere arbejde i et privat arbejdsområde under udvikling. Indholdsforfatteren synkroniserer en fjernforgrening (typisk en bestemt funktionsforgrening eller en fejlforgrening) fra Azure Repos til deres private arbejdsområde. Indholdsændringer synkroniseres mellem fjernforgreningen i Azure Repos og arbejdsområdet. I dette scenarie behøver oprettere af indhold ikke at bruge Azure Pipelines til at publicere indhold. Indholdsforfattere kan også regelmæssigt bekræfte og pushoverføre ændringer fra arbejdsområdet efter publicering. Når de er klar, kan indholdsoprettere foretage en pullanmodning for at flette deres ændringer til hovedgrenen.
	Når du bruger Git-integration, synkroniseres udviklingsarbejdsområdet med hovedgrenen for at få de nyeste versioner af indhold. Dette indhold indeholder alle ændringer fra pullanmodninger, som en udgivelseschef gennemgår, godkender og fletter.
	Arbejdsområder er angivet til Fabric-kapacitet, Premium-kapacitet, Premium pr. bruger eller Integreretlicenstilstand for at tillade brug af Power BI-udrulningspipelines og XMLA-slutpunktet for læsning/skrivning.
	En administrator af udrulningspipeline konfigurerer Power BI-udrulningspipelinen med tre faser: udvikling, test og produktion. Hver fase justeres efter et separat arbejdsområde i Power BI-tjeneste. Installationsindstillinger og adgang angives for udrulningspipelinen.
	Udviklingsarbejdsområdet indeholder de nyeste versioner af indhold, herunder alle godkendte og flettede ændringer. Når den er godkendt, udruller en udgivelsespipeline indhold fra udviklingen til testarbejdsområdet.
	Korrekturlæsere i testarbejdsområdet udfører test og kvalitetssikring af indhold. Når den er godkendt, udruller en udgivelsespipeline indhold fra testen til produktionsarbejdsområdet. Når du bruger Git-integration med udrulningspipelines, synkroniseres testarbejdsområdet ikke med nogen forgrening.
	Når udrulningspipelinen er fuldført, udfører indholdsoprettere manuelt aktiviteter efter udrulningen. Aktiviteter kan omfatte konfiguration af planlagt opdatering af data eller opdatering af en Power BI-app til produktionsarbejdsområdet. Når du bruger Git-integration med udrulningspipelines, synkroniseres produktionsarbejdsområdet ikke med nogen forgrening.
	Indholdsfremvisere får adgang til indholdet ved hjælp af produktionsarbejdsområdet eller en Power BI-app.

Tip

Vi anbefaler, at du også gennemser selvbetjeningsscenarierne for indholdsudgivelse og administration af avancerede datamodeller. Scenariet for udgivelse af virksomhedsindhold bygger på begreber, som disse scenarier introducerer.

Vigtige punkter

Følgende er nogle vigtige punkter, der skal understreges i forbindelse med scenariet for udgivelse af virksomhedsindhold.

Versionsstyring

Det er vigtigt at spore ændringer i indholdslivscyklussen for at sikre en stabil og ensartet levering af indhold til forbrugere. I dette forbrugsscenarie administrerer indholdsoprettere og -ejere indholdsændringer i et fjernlager ved hjælp af versionsstyring. Versionsstyring er praksis for administration af ændringer af filer eller kode i et centralt lager. Denne praksis giver mulighed for bedre samarbejde og effektiv administration af versionshistorik. Versionsstyring har fordele for oprettere af indhold, herunder muligheden for at annullere eller flette ændringer.

Indholdsforfattere udvikler typisk datamodeller i Tabeleditor for at understøtte bedre versionsstyring. I modsætning til en datamodel, som du udvikler i Power BI Desktop, gemmes en datamodel, der er udviklet i Tabular Editor , i metadataformat, der kan læses af mennesker. Dette format aktiverer versionsstyring på objektniveau for datamodeller. Du skal bruge versionsstyring på objektniveau, når du samarbejder med flere personer på den samme datamodel. Du kan få flere oplysninger i brugsscenariet for administration af avancerede datamodeller. Det er ikke muligt at se ændringer, du har foretaget i en Power BI Desktop-fil (.pbix), f.eks. rapportdefinitionen eller datamodellen. Du kan f.eks. ikke spore ændringer af en rapportside, f.eks. de visuelle elementer, der bruges, deres positioner og deres felttilknytninger eller formatering.

Indholdsoprettere gemmer metadatafiler til datamodeller og .pbix-filer i et centralt fjernlager, f.eks. Azure Repos. Disse filer er kurateret af en teknisk ejer. Selvom en indholdsopretter udvikler en løsning, er en teknisk ejer ansvarlig for at administrere løsningen og gennemgå ændringerne og flette dem til en enkelt løsning. Azure Repos indeholder avancerede muligheder for sporing og administration af ændringer. Denne fremgangsmåde adskiller sig fra den fremgangsmåde, der er beskrevet i selvbetjeningsscenariet for indholdsudgivelse , hvor forfatteren bruger OneDrive-lager med versionssporing. Det er vigtigt at vedligeholde et veldokumenteret lager, da det er grundlaget for alt indhold og samarbejde.

Her er nogle vigtige overvejelser, der kan hjælpe dig med at konfigurere et fjernlager til versionsstyring.

• Område: Definer klart lagerets omfang. Ideelt set er lagerets omfang identisk med omfanget af de downstreamarbejdsområder og apps, du bruger til at levere indhold til forbrugere.
• Adgang: Du skal konfigurere adgang til lageret ved hjælp af en lignende tilladelsesmodel, som du har konfigureret for dine udrulningspipelinetilladelser og arbejdsområderoller. Oprettere af indhold skal have adgang til lageret.
• dokumentation: Føj tekstfiler til lageret for at dokumentere dets formål, ejerskab, adgang og definerede processer. I dokumentationen kan du f.eks. beskrive, hvordan ændringer skal gemmes og bekræftes.
• Tools: Hvis du vil bekræfte og overføre ændringer til et fjernlager, skal indholdsoprettere have en Git-klient, f.eks. Visual Studio eller Visual Studio Code. Git er et distribueret versionskontrolsystem, der sporer ændringer i dine filer. Hvis du vil vide mere om Grundlæggende oplysninger om Git, skal du se Hvad er Git?.

Bemærk

Overvej at bruge Git Large File Storage (LFS), hvis du planlægger at bekræfte Power BI Desktop-filer (.pbix). Git LFS indeholder avancerede indstillinger til administration af filer, hvor ændringer ikke er synlige (uoverensklede filer), f.eks. en .pbix-fil. Du kan f.eks. bruge fillåsning til at forhindre samtidige ændringer i en Power BI-rapport under udvikling. Git LFS har dog sin egen klient og konfiguration.

Samarbejde med Azure DevOps

I takt med at en løsning øger omfanget og kompleksiteten, kan det blive nødvendigt for flere indholdsforfattere og -ejere at arbejde i samarbejde. Indholdsforfattere og -ejere kommunikerer og samarbejder i en central, organiseret hub ved hjælp af Azure DevOps.

Hvis du vil samarbejde og kommunikere i Azure DevOps, skal du bruge supporttjenester.

• Azure Boards: Indholdsejere bruger tavler til at spore arbejdselementer. Arbejdselementer tildeles hver især til en enkelt udvikler i teamet, og de beskriver problemer, fejl eller funktioner i løsningen og de tilsvarende interessenter.
• Azure Wiki: Indholdsoprettere deler oplysninger med deres team for at forstå og bidrage til løsningen.
• Azure Repos: Indholdsoprettere sporer ændringer i fjernlageret og fletter dem til en enkelt løsning.
• Azure Pipelines: Pipelineejere konfigurerer programmatisk logik for at installere løsningen enten automatisk eller efter behov.

Samarbejdsrutediagram

I følgende diagram vises en oversigt på højt niveau over ét eksempel på, hvordan Azure DevOps muliggør samarbejde i brugsscenariet for udgivelse af virksomhedsindhold. I dette diagram fokuseres der på brugen af Azure DevOps til at oprette en struktureret og dokumenteret indholdsudgivelsesproces.

Diagrammet viser følgende brugerhandlinger, processer og funktioner.

Punkt	Beskrivelse
	En indholdsopretter opretter en ny kortlivet forgrening ved at klone hovedforgreningen, som indeholder den nyeste version af indholdet. Den nye forgrening kaldes ofte funktionsgrenen, da den bruges til at udvikle en bestemt funktion eller løse et bestemt problem.
	Indholdsforfatteren bekræfter sine ændringer i et lokalt lager under udvikling.
	Indholdsforfatteren linker deres ændringer til arbejdselementer, der administreres i Azure Boards. Works-elementer beskriver specifikke udviklinger, forbedringer eller fejlrettelser, der er begrænset til deres forgrening.
	Indholdsforfatteren udfører jævnligt deres ændringer. Når du er klar, publicerer indholdsforfatteren deres forgrening til fjernlageret.
	Hvis du vil teste deres ændringer, udruller indholdsforfatteren deres løsning til et isoleret arbejdsområde til deres udvikling (ikke vist i dette diagram). Indholdsforfatteren kan også synkronisere funktionsforgreningen til arbejdsområdet ved hjælp af Fabric Git-integration.
	Indholdsforfattere og indholdsejere dokumenterer løsningen og dens processer i en Azure Wiki, som er tilgængelig for hele udviklingsteamet.
	Når du er klar, åbner indholdsforfatteren en pullanmodning for at flette funktionsgrenen til hovedgrenen.
	En teknisk ejer er ansvarlig for at gennemgå pullanmodningen og flette ændringer. Når de godkender pullanmodningen, fletter de funktionsgrenen ind i hovedgrenen.
	En vellykket fletning udløser udrulning af løsningen til et udviklingsarbejdsområde ved hjælp af en Azure Pipeline (ikke vist i dette diagram). Når du bruger Fabric Git-integration, synkroniseres hovedforgreningen til udviklingsarbejdsområdet.
	Udgivelsesadministratoren udfører en endelig gennemgang og godkendelse af løsningen. Denne udgivelsesgodkendelse forhindrer, at løsningen publiceres, før den er klar. I publicering af virksomhedsindhold planlægger og koordinerer en udgivelseschef typisk indholdsudgivelsen til test- og produktionsarbejdsområder. De koordinerer og kommunikerer med indholdsforfattere, interessenter og brugere.
	Når udgivelsesadministratoren godkender udgivelsen, forbereder Azure Pipelines automatisk løsningen til udrulning. En Azure Pipeline kan også udløse en udrulningspipeline for at fremhæve indhold mellem arbejdsområder.
	Brugerne tester og validerer indhold i testarbejdsområdet. Når du bruger Git-integration med Azure Pipelines til udrulning, synkroniseres testarbejdsområdet ikke med nogen forgrening.
	Når brugerne har accepteret og valideret ændringer, udfører udgivelsesadministratoren en endelig gennemgang og godkendelse af den løsning, der skal installeres i produktionsarbejdsområdet.
	Brugerne får vist indhold, der er publiceret i produktionsarbejdsområdet. Når du bruger Git-integration med Azure Pipelines til udrulning, synkroniseres produktionsarbejdsområdet ikke med nogen forgrening.

Indholdsoprettere opnår samarbejde ved hjælp af en forgreningsstrategi for at uddybe det. En forgreningsstrategi er, hvordan indholdsoprettere opretter, bruger og fletter forgreninger til effektivt at foretage og administrere indholdsændringer. Individuelle indholdsforfattere arbejder isoleret i deres lokale lager. Når de er klar, kombinerer de deres ændringer som en enkelt løsning i fjernlageret. Indholdsoprettere skal begrænse deres arbejde til forgreninger ved at knytte dem til arbejdselementer for specifikke udviklinger, forbedringer eller fejlrettelser. Hver indholdsopretter opretter sin egen forgrening af fjernlageret for deres arbejdsområde. Arbejde udført på deres lokale løsning bekræftes og pushes til en version af forgreningen i fjernlageret med en bekræftelsesmeddelelse. En bekræftelsesmeddelelse beskriver de ændringer, der er foretaget i den pågældende bekræftelse.

Hvis du vil flette ændringerne, åbner en indholdsopretter en pullanmodning. En pullanmodning er en indsendelse til peer review, der kan føre til fletning af det udførte arbejde til en enkelt løsning. Fletning kan resultere i konflikter, som skal løses, før forgreningen kan flettes. Pullanmodningsgennemgange er vigtige for at sikre, at oprettere overholder organisationens standarder og fremgangsmåder for udvikling, kvalitet og overholdelse af angivne standarder.

Samarbejdsanbefalinger

Vi anbefaler, at du definerer en struktureret proces for, hvordan indholdsoprettere skal samarbejde. Sørg for, at du bestemmer:

• Sådan arbejde er begrænset, og hvordan forgreninger oprettes, navngives og bruges.
• Sådan grupperer forfattere ændringer og beskriver dem med bekræftelsesmeddelelser.
• Hvem er ansvarlig for at gennemgå og godkende pullanmodninger.
• Sådan løses flettekonflikter.
• Sådan flettes ændringer, der er foretaget i forskellige forgreninger, sammen til en enkelt forgrening.
• Sådan testes indhold, og hvem der udfører test, før indhold udrulles.
• Hvordan og hvornår ændringer udrulles til udviklings-, test- og produktionsarbejdsområder.
• Hvordan og hvornår udrullede ændringer eller versioner af løsningen skal annulleres.

Vigtigt

Den værdi, der leveres af DevOps, er direkte proportional med overholdelse af de processer, der definerer brugen af den.

Et vellykket samarbejde afhænger af en veldefineret proces. Det er vigtigt at beskrive og dokumentere arbejdsprocessen for udvikling fra ende til anden. Sørg for, at de valgte strategier og processer stemmer overens med eksisterende praksisser i dit team, og hvis ikke, hvordan du administrerer ændringer. Sørg desuden for, at processerne er tydelige og kommunikeret til alle teammedlemmer og interessenter. Sørg for, at teammedlemmer og interessenter, der er nye i processerne, oplæres i, hvordan de skal adopteres, og at de sætter pris på værdien af en vellykket DevOps-implementering.

REST-API'er til Power BI

Du udvikler programmatisk logik til at importere og udrulle indhold fra Azure DevOps ved hjælp af REST API'erne til Power BI. Du importerer Power BI-filer (.pbix) til et arbejdsområde ved hjælp af en importhandling. Du bruger en pipelinehandling til at udrulle noget indhold eller alt indhold til test- eller produktionsarbejdsområder ved hjælp af Power BI-udrulningspipelines. Den programmatiske logik er defineret i Azure Pipelines.

Vi anbefaler, at du bruger en tjenesteprincipal til at kalde REST API'er til Power BI i dine pipelines. En tjenesteprincipal er beregnet til automatiske, automatiserede aktiviteter, og den er ikke afhængig af brugerlegitimationsoplysninger. Nogle elementer og aktiviteter understøttes dog ikke af REST API'er til Power BI, eller når du bruger en tjenesteprincipal, f.eks. dataflow.

Når du bruger en tjenesteprincipal, skal du sørge for omhyggeligt at administrere tilladelser. Dit mål bør være at følge princippet om mindst mulige rettigheder. Du skal angive tilstrækkelige tilladelser for tjenesteprincipalen uden overklareringstilladelser. Brug Azure Key Vault eller en anden tjeneste, der sikkert gemmer tjenesteprincipalens hemmeligheder og legitimationsoplysninger.

Advarsel

Hvis du har en datamodel, der er gemt som et metadataformat, der kan læses af mennesker, kan den ikke publiceres ved hjælp af REST API'erne til Power BI. Du skal i stedet publicere den ved hjælp af XMLA-slutpunktet. Du kan publicere metadatafiler ved hjælp af tredjepartsværktøjer, f.eks. kommandolinjegrænsefladen i Tabular Editor . Du kan også publicere metadatafiler programmeringsmæssigt ved hjælp af din egen brugerdefinerede .NET-udvikling. Det kræver en større indsats at udvikle en brugerdefineret løsning, da du skal bruge UDVIDELSEN TOM (Microsoft Tabular Object Model) til AMO-klientbibliotekerne (Analysis Management Object).

Azure Pipelines

Azure Pipelines automatiserer programmeringsmæssigt test, administration og udrulning af indhold. Når der køres en pipeline, udføres trinnene i pipelinen automatisk. Pipelineejere kan tilpasse udløsere, trin og funktionalitet, så de opfylder installationsbehovene. Antallet og typerne af pipelines varierer derfor afhængigt af løsningskravene. En Azure Pipeline kan f.eks. køre automatiserede test eller ændre parametre for datamodeller før en udrulning.

Der er tre typer Azure Pipelines, som du kan konfigurere til at teste, administrere og installere din Power BI-løsning:

• Valideringspipelines.
• Opret pipelines.
• Slip pipelines.

Bemærk

Det er ikke nødvendigt at have alle tre af disse pipelines i din udgivelsesløsning. Afhængigt af din arbejdsproces og dine behov kan du konfigurere en eller flere varianter af de pipelines, der er beskrevet i denne artikel, for at automatisere indholdspublikationen. Denne mulighed for at tilpasse pipelines er en fordel ved Azure Pipelines i forhold til de indbyggede Power BI-udrulningspipelines. Du behøver f.eks. ikke at have en valideringspipeline. Du kan kun bruge build- og udgivelsespipelines.

Valideringspipelines

Valideringspipelines udfører grundlæggende kvalitetskontrol af datamodeller, før de publiceres i et udviklingsarbejdsområde. Ændringer i en forgrening af fjernlageret udløser typisk pipelinen for at validere disse ændringer med automatiseret test.

Eksempler på automatiseret test omfatter scanning af datamodellen for bedste praksis-regelovertrædelser ved hjælp af BPA (Best Practice Analyzer ) eller ved at køre DAX-forespørgsler mod en publiceret semantisk model. Resultaterne af disse test gemmes derefter i fjernlageret med henblik på dokumentation og overvågning. Datamodeller, der ikke valideres, bør ikke publiceres. Pipelinen skal i stedet give indholdsoprettere besked om problemerne.

Opret pipelines

Opret pipelines, der forbereder datamodeller til publicering på Power BI-tjeneste. Disse pipelines kombinerer serialiserede modelmetadata i en enkelt fil, der senere udgives af en udgivelsespipeline (beskrevet i diagrammet over udgivelsespipelines). En buildpipeline kan også foretage andre ændringer af metadataene, f.eks. ændring af parameterværdier. Buildpipelines producerer udrulningsartefakter, der består af datamodelmetadata (til datamodeller) og Power BI Desktop-filer (.pbix), der er klar til publicering til Power BI-tjeneste.

Frigiv pipelines

Udgiv pipelines, der publicerer eller udruller indhold. En udgivelsesløsning indeholder typisk flere udgivelsespipelines, afhængigt af destinationsmiljøet.

• udviklingsudgivelsespipeline: Denne første pipeline udløses automatisk. Det publicerer indhold til et udviklingsarbejdsområde, når build- og valideringspipelines er fuldført.
• test- og produktionsudgivelsespipelines: Disse pipelines udløses ikke automatisk. De udløses i stedet efter behov eller godkendes. Test- og produktionsudgivelsespipelines udruller indhold til henholdsvis en test eller et produktionsarbejdsområde efter udgivelsesgodkendelse. Udgivelsesgodkendelser sikrer, at indhold ikke automatisk udrulles til en test- eller produktionsfase, før det er klar. Disse godkendelser leveres af udgivelsesadministratorer, der er ansvarlige for planlægning og koordinering af indholdsudgivelse til test- og produktionsmiljøer.

Der er to forskellige metoder til at publicere indhold med test- og udgivelsespipelines. De fremhæver enten indhold ved hjælp af en Power BI-udrulningspipeline, eller de publicerer indhold til Power BI-tjeneste fra Azure DevOps.

I følgende diagram vises den første fremgangsmåde. I denne fremgangsmåde orkestrer udgivelsespipelines indholdsinstallation til test- og produktionsarbejdsområder ved hjælp af Power BI-udrulningspipelines. Indhold fremmes via udviklings-, test- og produktionsarbejdsområder i Power BI. Selvom denne fremgangsmåde er mere robust og enklere at vedligeholde, kræver den Premium-licensering.

Diagrammet viser følgende brugerhandlinger, processer og funktioner i den første tilgang.

Punkt	Beskrivelse
	I den første fremgangsmåde publicerer udgivelsespipelines indhold ved hjælp af XMLA-slutpunktet og REST API'erne til Power BI med Power BI-udrulningspipelines. Indhold publiceres og hæves derefter via udviklings-, test- og produktionsarbejdsområder. Power BI-udrulningspipelines og XMLA-slutpunktet for læsning/skrivning er Premium-funktioner.
	En vellykket forgreningsfletning eller fuldførelse af en upstream-pipeline udløser buildpipelinen. Buildpipelinen forbereder derefter indhold til publicering og udløser udviklingsudgivelsespipelinen.
	Udviklingsudgivelsespipelinen publicerer indhold til udviklingsarbejdsområdet ved hjælp af XMLA-slutpunktet (til metadata for datamodeller) eller Power BI REST API'er (til Power BI Desktop-filer, som kan indeholde datamodeller og rapporter). Udviklingspipelinen bruger kommandolinjegrænsefladen i Tabular Editor til at installere metadata for datamodeller ved hjælp af XMLA-slutpunktet.
	En udgivelsesgodkendelses- eller on-demand-udløser aktiverer testudgivelsespipelinen.
	Testudgivelsespipelinen udruller indhold ved hjælp af Power BI REST API-udrulningshandlinger, der kører Power BI-udrulningspipelinen.
	Power BI-udrulningspipelinen hæver indhold fra udviklingsarbejdsområdet til testarbejdsområdet. Efter udrulningen udfører udgivelsespipelinen aktiviteter efter udrulningen ved hjælp af REST API'erne til Power BI (ikke vist i diagrammet).
	En udgivelsesgodkendelses- eller on-demand-udløser aktiverer produktionsudgivelsespipelinen.
	Produktionsudgivelsespipelinen udruller indhold ved hjælp af Power BI REST API-udrulningshandlinger, der kører Power BI-udrulningspipelinen.
	Power BI-udrulningspipelinen hæver indhold fra testarbejdsområdet til produktionsarbejdsområdet. Efter udrulningen udfører udgivelsespipelinen aktiviteter efter udrulningen ved hjælp af REST API'erne til Power BI (ikke vist i diagrammet).

I følgende diagram beskrives den anden fremgangsmåde. Denne fremgangsmåde bruger ikke udrulningspipelines. I stedet bruges udgivelsespipelines til at publicere indhold til test- og produktionsarbejdsområder fra Azure DevOps. Denne anden fremgangsmåde kræver ikke Premium-licenser, når du kun publicerer Power BI Desktop-filer med REST API'er til Power BI. Det omfatter en større konfigurationsindsats og kompleksitet, fordi du skal administrere udrulning uden for Power BI. Udviklingsteams, der allerede bruger DevOps til dataløsninger uden for Power BI, kender måske denne fremgangsmåde. Udviklingsteams, der bruger denne fremgangsmåde, kan konsolidere udrulningen af dataløsninger i Azure DevOps.

Diagrammet viser følgende brugerhandlinger, processer og funktioner i den anden fremgangsmåde.

Punkt	Beskrivelse
	I den anden fremgangsmåde publicerer udgivelsespipelines indhold ved kun at bruge XMLA-slutpunktet og REST API'erne til Power BI. Indhold publiceres til udviklings-, test- og produktionsarbejdsområder.
	En vellykket forgreningsfletning eller fuldførelse af en upstream-pipeline udløser buildpipelinen. Buildpipelinen forbereder derefter indhold til publicering og udløser udviklingsudgivelsespipelinen.
	Udviklingsudgivelsespipelinen publicerer indhold til udviklingsarbejdsområdet ved hjælp af XMLA-slutpunktet (til metadata for datamodeller) eller Power BI REST API'er (til Power BI Desktop-filer, som kan indeholde datamodeller og rapporter). Udviklingspipelinen bruger kommandolinjegrænsefladen i Tabular Editor til at installere metadata for datamodeller ved hjælp af XMLA-slutpunktet.
	En udgivelsesgodkendelses- eller on-demand-udløser aktiverer testudgivelsespipelinen.
	Udviklingsudgivelsespipelinen publicerer indhold til testarbejdsområdet ved hjælp af XMLA-slutpunktet (for datamodelmetadata) eller Power BI REST API'er (til Power BI Desktop-filer, som kan indeholde datamodeller og rapporter). Udviklingspipelinen bruger kommandolinjegrænsefladen i Tabular Editor til at installere metadata for datamodeller ved hjælp af XMLA-slutpunktet. Efter udrulningen udfører udgivelsespipelinen aktiviteter efter udrulningen ved hjælp af REST API'erne til Power BI (ikke vist i diagrammet).
	En udgivelsesgodkendelses- eller on-demand-udløser aktiverer produktionsudgivelsespipelinen.
	Udviklingsudgivelsespipelinen publicerer indhold til produktionsarbejdsområdet ved hjælp af XMLA-slutpunktet (til datamodelmetadata) eller Power BI REST API'er (til Power BI Desktop-filer, som kan indeholde datamodeller og rapporter). Udviklingspipelinen bruger kommandolinjegrænsefladen i Tabular Editor til at installere metadata for datamodeller ved hjælp af XMLA-slutpunktet. Efter udrulningen udfører udgivelsespipelinen aktiviteter efter udrulningen ved hjælp af REST API'erne til Power BI (ikke vist i diagrammet).

Udgivelsespipelines skal administrere aktiviteter efter udrulning. Disse aktiviteter kan omfatte angivelse af legitimationsoplysninger for semantiske modeller eller opdatering af Power BI-appen til test- og produktionsarbejdsområder. Vi anbefaler, at du konfigurerer meddelelser for at informere relevante personer om udrulningsaktiviteter.

Tip

Brug af et lager til versionsstyring gør det muligt for indholdsoprettere at oprette en annulleringsproces. Annulleringsprocessen kan fortryde den seneste installation ved at gendanne den tidligere version. Overvej at oprette et separat sæt Azure Pipelines, som du kan udløse for at annullere produktionsændringer. Tænk nøje over, hvilke processer og godkendelser der kræves for at starte en annullering. Sørg for, at disse processer er dokumenteret.

Udrulningspipelines til Power BI

En Power BI-udrulningspipeline består af tre faser: udvikling, test og produktion. Du tildeler et enkelt Power BI-arbejdsområde til hver fase i udrulningspipelinen. Når der sker en udrulning, hæver udrulningspipelinen Power BI-elementer fra ét arbejdsområde til et andet.

En Azure Pipelines-udgivelsespipeline bruger Power BI REST API'er til at udrulle indhold ved hjælp af en Power BI-udrulningspipeline. Adgang til både arbejdsområdet og udrulningspipelinen er påkrævet for de brugere, der udfører en udrulning. Vi anbefaler, at du planlægger adgang til udrulningspipelines, så brugere af pipelinen kan få vist udrulningshistorikken og sammenligne indhold.

Tip

Når du adskiller dataarbejdsområder fra rapporteringsarbejdsområder, kan du overveje at bruge Azure Pipelines til at orkestrere indholdspublicering med flere Power BI-udrulningspipelines. Semantisk model udrulles først, og derefter opdateres de. Endelig installeres rapporter. Denne fremgangsmåde hjælper dig med at forenkle udrulningen.

Premium-licenser

Power BI-udrulningspipelines og XMLA-slutpunktet for læsning/skrivning er Premium-funktioner. Disse funktioner er tilgængelige med Power BI Premium-kapacitet og Power BI Premium pr. bruger.

Premium pr. bruger er en omkostningseffektiv måde at administrere publicering af virksomhedsindhold til udviklings- og testarbejdsområder på, som typisk har få brugere. Denne fremgangsmåde har den ekstra fordel, at udviklings- og testarbejdsbelastninger isoleres fra produktionsarbejdsbelastninger.

Bemærk

Du kan stadig konfigurere publicering af virksomhedsindhold uden en Premium-licens, som beskrevet i den anden fremgangsmåde i afsnittet om udgivelsespipeline . I den anden fremgangsmåde bruger du Azure Pipelines til at administrere udrulningen af Power BI Desktop-filer til udviklings-, test- og produktionsarbejdsområder. Du kan dog ikke installere modelmetadata ved hjælp af XMLA-slutpunktet, fordi det ikke er muligt at publicere en semantisk metadataformatmodel med REST API'erne til Power BI. Det er heller ikke muligt at fremhæve indhold via miljøer med udrulningspipelines uden en Premium-licens.

Konfiguration af gateway

Der kræves typisk en datagateway, når du får adgang til datakilder, der er placeret i det private organisationsnetværk eller et virtuelt netværk. De to formål med en gateway er at opdatere importerede data og få vist en rapport, der forespørger en direkte forbindelse eller en DirectQuery-semantisk model (ikke afbildet i scenariediagrammet).

Når du arbejder med flere miljøer, er det almindeligt at konfigurere udviklings-, test- og produktionsforbindelser til forskellige kildesystemer. I dette tilfælde skal du bruge datakilderegler og parameterregler til at administrere værdier, der adskiller sig fra miljøer. Du kan bruge Azure Pipelines til at administrere gateways ved hjælp af gatewayhandlinger for REST API'erne til Power BI.

Bemærk

En central datagateway i standardtilstand anbefales på det kraftigste via gateways i personlig tilstand. I standardtilstand understøtter datagatewayen direkte forbindelse og DirectQuery-handlinger (ud over planlagte dataopdateringshandlinger).

Systemtilsyn

Aktivitetsloggen registrerer hændelser, der forekommer i Power BI-tjeneste. Power BI-administratorer kan bruge aktivitetsloggen til at overvåge udrulningsaktiviteter.

Du kan bruge API'er til scanning af Power BI-metadata til at oprette en lejeroversigt. API-resultaterne er nyttige til at kontrollere, hvilke elementer der er installeret i hvert arbejdsområde, til at kontrollere afstamning og til at validere sikkerhedsindstillinger.

Der er også en overvågningslog i Azure DevOps, som er uden for Power BI-tjeneste. Azure DevOps-administratorer kan bruge overvågningsloggen til at gennemse aktiviteter i fjernlagre og pipelines.

Relateret indhold

Du kan finde andre nyttige scenarier, der kan hjælpe dig med power BI-implementeringsbeslutninger, i artiklen Power BI-forbrugsscenarier .