Planlegging av Power BI-implementering: Distribuer innhold

Notat

Denne artikkelen er en del av Power BI-implementeringsplanlegging serie med artikler. Denne serien fokuserer hovedsakelig på Power BI-opplevelsen i Microsoft Fabric. Hvis du vil ha en innføring i serien, kan du se planlegging av Power BI-implementering.

Denne artikkelen hjelper deg med å distribuere innhold som en del av administrasjonen av innholdslivssyklusen. Det er primært rettet mot:

• Fabric-administratorer: Administratorene som er ansvarlige for å overvåke Fabric i organisasjonen. Stoffadministratorer må kanskje samarbeide med andre administratorer, for eksempel de som fører tilsyn med Microsoft 365 eller Azure DevOps.
• Center of Excellence (COE) og BI-team: Teamene som er ansvarlige for å overvåke Power BI i organisasjonen. Disse teamene inkluderer beslutningstakere som bestemmer hvordan de skal administrere livssyklusen til Power BI-innhold. Disse teamene kan også inkludere utgivelsesledere, som håndterer livssyklusen til innholdsutgivelser, og teknikere som oppretter og administrerer komponentene som trengs for å effektivt bruke og støtte livssyklusadministrasjon.
• innholdsopprettere og innholdseiere: Brukere som oppretter innhold som de vil publisere til Fabric-portalen for å dele med andre. Disse personene er ansvarlige for å administrere livssyklusen til Power BI-innholdet de oppretter.

Livssyklusbehandling består av prosessene og praksisene du bruker til å håndtere innhold fra opprettingen til eventuell pensjonering. I den tredje fasen av livssyklusbehandlingvaliderer du innholdsendringer, som innebærer validering utført av både innholdsopprettere og brukere. I fjerde fase distribuerer du innhold for forbrukere for å bruke det.

Hvis du vil dele Power BI-innhold med forbrukere, bør du først publisere (eller distribuere) innholdet til et Fabric-arbeidsområde. Distribusjon av innhold innebærer også flytting av innholdet mellom miljøer, for eksempel distribusjon fra et arbeidsområde for utvikling til et testarbeidsområde, eller fra et testarbeidsområde til et produksjonsarbeidsområde.

Bildet nedenfor viser livssyklusen til Power BI-innhold, utheving av trinn fire, der du distribuerer innhold.

Notat

Hvis du vil ha en oversikt over behandling av innholdslivssyklus, kan du se den første artikkelen i denne serien.

Denne artikkelen fokuserer på viktige hensyn og beslutninger for distribusjon av innhold gjennom hele livssyklusen. Hvis du vil ha mer veiledning om hvordan du distribuerer innhold, kan du se:

• Overføre til Power BI: Distribuer innhold: Denne artikkelen beskriver viktige hensyn og beslutninger for distribusjon når du overfører til Power BI fra andre teknologier.
• løsningsplanlegging for BI: Distribuer, støtte og overvåk: Denne artikkelen beskriver hvordan du planlegger distribusjon når du oppretter Power BI- eller Fabric-løsningen.
• planlegging av implementering av Power BI: Selvbetjent bruksscenario for innholdspublisering: Denne artikkelen beskriver hvordan selvbetjente brukere kan distribuere innhold ved hjelp av distribusjonssamlebånd for OneDrive for arbeid og skole og stoff.
• planlegging av Power BI-implementering: Enterprise-innholdspubliseringsbruksscenario: Denne artikkelen beskriver hvordan sentrale team kan distribuere og administrere innhold ved hjelp av Azure DevOps.

Du distribuerer innhold på to hovedpunkter i løpet av innholdslivssyklusen:

• Når du publiserer innhold til et arbeidsområde for utvikling. Nå publiserer du innhold for å validere endringene.
• Når du hever innhold mellom to arbeidsområder (for eksempel promotering av innhold fra et arbeidsområde for utvikling til et testarbeidsområde). Nå distribuerer du innhold når det er klart for neste fase (for eksempel når nytt innhold er klart til å testes).

Avsnittene nedenfor beskriver fremgangsmåter du kan bruke til å publisere eller heve innhold.

Bestem hvordan du skal publisere innhold

Når du utvikler innhold på den lokale maskinen, må du publisere innholdet til et utviklingsarbeidsområde i Stoff-portalen. Du publiserer vanligvis dette innholdet når du vil utføre validering av endringene du har gjort.

Notat

I denne artikkelen refererer vi til publisering innhold som den første distribusjonen til utviklingsarbeidsområdet. Men i prinsippet er publisering av innhold det samme som å distribuere det.

Innhold som er opprettet i Stoff-portalen (for eksempel dataflyter, instrumentbord og målstyringer) opprettes direkte i utviklingsarbeidsområdet, og trenger ikke å publiseres.

Avsnittene nedenfor beskriver ulike fremgangsmåter du kan ta for å publisere innhold.

Publiser med Power BI Desktop

Med Power BI Desktop kan brukere publisere semantiske modeller og rapporter fra den lokale maskinen til et arbeidsområde i Fabric-portalen. Denne fremgangsmåten er den enkleste måten å publisere innhold på. Den kan imidlertid ikke automatiseres.

Vurder å bruke denne fremgangsmåten når:

• Innholdsopprettere foretrekker å manuelt kontrollere innholdspublisering til Stoff-portalen.
• Innholdsopprettere bruker Power BI Desktop til å utvikle og behandle innhold.
• Innholdsopprettere er ikke kjent med Azure DevOps eller Git.
• Innhold består bare av semantiske modeller eller rapporter.

Publiser med tredjepartsverktøy

Tredjepartsverktøy gjør det mulig for innholdsopprettere å publisere en semantisk modell ved hjelp av arbeidsområdet XMLA-lese-/skriveendepunkt. En innholdsoppretter bruker for eksempel Tabellredigering til å utvikle og behandle modellmetadata, for eksempel TMDL -filer (tabellmodelldefinisjonsspråk) eller BIM-filer.

Tips

Hvis du vil ha mer informasjon om hvordan du bruker tredjepartsverktøy til å distribuere semantiske modeller, kan du se avansert bruksscenario for datamodellbehandling.

Hvis du vil ha mer informasjon om hvordan du kan aktivere og bruke XMLA-lese-/skriveendepunkter, kan du se semantisk modelltilkobling med XMLA-endepunktet.

Vurder å bruke denne fremgangsmåten når:

• Innholdsopprettere foretrekker å manuelt kontrollere innholdspublisering til Stoff-portalen.
• Innholdsopprettere bruker et tredjepartsverktøy til å utvikle og administrere innholdet.
• Innhold publiseres til et arbeidsområde som bruker Premium per bruker (PPU), Premium-kapasitet eller stoffkapasitetslisensmodus.
• Innholdsopprettere er ikke kjent med Azure DevOps eller Git.
• Innhold består bare av semantiske modeller.

Publiser med OneDrive-oppdatering

Med OneDrive kan selvbetjente innholdsopprettere automatisk publisere semantiske modeller eller rapporter til et arbeidsområde i Fabric-portalen ved hjelp av OneDrive-oppdatering. Innholdsopprettere kan lagre Power BI Desktop-filer (PBIX) i et delt bibliotek i OneDrive. Det delte biblioteket kan også være et SharePoint- eller Microsoft Teams-dokumentbibliotek.

Tips

Hvis du vil ha mer informasjon om hvordan du bruker OneDrive for arbeid og skole med Power BI-innhold, kan du se selvbetjent bruksscenario for innholdspublisering.

Hvis du vil ha mer informasjon om hvordan du kan konfigurere OneDrive-oppdatering, kan du se Oppdatere en semantisk modell som er lagret på OneDrive- eller SharePoint Online-.

Vurder å bruke denne fremgangsmåten når:

• Innholdsopprettere vil automatisere innholdspublisering til Stoff-portalen.
• Innholdsopprettere er ikke kjent med Azure DevOps eller Git.
• Innholdsopprettere utfører versjonskontroll over innhold ved hjelp av OneDrive eller SharePoint.
• Innholdsopprettere lagrer semantiske modeller og rapporter som PBIX-filer.
• Innhold består bare av semantiske modeller eller rapporter.

Publiser med Fabric Git-integrering

Fabric Git-integrering er en funksjon eksklusiv for stoffkapasiteter som gjør det mulig for innholdsopprettere å synkronisere en gren fra et eksternt Git-repositorium til et Fabric-arbeidsområde. Du kan bruke Git-integrering sammen med Azure DevOps til å synkronisere innhold fra Azure Repos, eller du kan distribuere innhold ved hjelp av Azure Pipelines (beskrevet i neste del).

Notat

Azure DevOps er en pakke med tjenester som integreres med Power BI og Fabric for å hjelpe deg med å planlegge og organisere administrasjon av innholdslivssyklus. Når du bruker Azure DevOps på denne måten, bruker du vanligvis følgende tjenester:

• Azure Repos: Lar deg opprette og bruke et eksternt Git-repositorium, som er en ekstern lagringsplassering du bruker til å spore og behandle innholdsendringer.
• Azure Pipelines: Lar deg opprette og bruke et sett med automatiserte oppgaver til å håndtere, teste og distribuere innhold fra et eksternt repositorium til et arbeidsområde.
• Azure Test Plans: Lar deg utforme tester for å validere løsningen og automatisere kvalitetskontrollen sammen med Azure Pipelines.
• Azure Boards: Lar deg bruke tavler til å spore oppgaver og planer som arbeidselementer, og koble eller referere til arbeidselementer fra andre Azure DevOps-tjenester.
• Azure Wiki: Lar deg dele informasjon med teamet for å forstå og bidra til innhold.

Hvis du vil oppsummere, publiseres innhold som er forpliktet og sendt til det eksterne repositoriet automatisk til arbeidsområdet via denne synkroniseringsprosessen. En viktig fordel med denne fremgangsmåten er at den lar deg koble sammen kildekontrollstyring prosesser med innholdspublikasjon. Det gir for eksempel enklere tilbakerulling av endringer eller hele versjoner av en løsning.

Tips

Hvis du vil ha mer informasjon om hvordan du bruker Fabric Git-integrering til å distribuere Power BI-innhold, kan du se bruksscenario for publisering av virksomhetsinnhold.

Hvis du vil ha mer informasjon om hvordan du kan konfigurere Git-integrering, kan du se Opplæring: Livssyklusadministrasjon i Fabric og Power BI Desktop-prosjekter: Git-integrering.

Vurder å bruke denne fremgangsmåten når:

• Innholdsopprettere er kjent med Azure DevOps og Git.
• Innholdsopprettere bruker Azure DevOps for samarbeid og kildekontroll.
• Innholdsopprettere lagrer semantiske modeller og rapporter som Power BI-prosjekt (PBIP) filer.
• Innhold publiseres til et arbeidsområde på en Fabric-kapasitet.
• Innhold består av støttede elementtyper av Git-integreringsfunksjonen.
• Innhold har ikke følsomhetsetiketter.

Notat

Hvordan du bruker Git-integrering til å distribuere og administrere innhold, er sterkt avhengig av forgrenings- og sammenslåingsstrategier, som du bestemmer i fase to av livssyklusbehandling.

Publiser med Azure Pipelines

Azure Pipelines automatiserer programmatisk testing, administrasjon og distribusjon av innhold. Når et datasamlebånd kjøres, utføres trinn i datasamlebåndet automatisk. Azure Pipelines er mer komplisert og krever mer tid og krefter for å konfigurere sammenlignet med andre tilnærminger, men det gir mest kontroll og fleksibilitet til å organisere distribusjonsprosessen.

Tips

Du kan distribuere innhold ved hjelp av Azure Pipelines og REST-API-er for Power BI til arbeidsområder som ikke er på Fabric- eller Premium-kapasitet. Fabric REST-API-ene fungerer imidlertid bare med Fabric, og XMLA-endepunktene fungerer bare med Fabric- eller Premium-kapasitet.

Hvis du vil ha mer informasjon om hvordan du bruker Azure Pipelines til å distribuere Power BI-innhold, kan du se bruksscenario for publisering av virksomhetsinnhold.

Hvis du vil ha mer informasjon om hvordan du kan integrere Azure DevOps med Power BI, kan du se Power BI Desktop-prosjekter Azure DevOps-integrering og bygge datasamlebånd.

Vurder å bruke Azure Pipelines til å organisere innholdsdistribusjon når:

• Innholdsopprettere er kjent med Azure DevOps og FABRIC REST API-er.
• Innholdsopprettere bruker Azure DevOps for samarbeid og kildekontroll.
• Innholdsopprettere bruker ikke Fabric Git-integrering.

Azure Pipelines og andre kodebaserte verktøy kan distribuere innhold programmatisk ved hjelp av ett eller flere av følgende API-er eller endepunkter:

• REST-API-er for Power BI: Det finnes forskjellige POWER BI REST API-endepunkter som du kan bruke til å distribuere innhold. REST-API-ene for Power BI støtter bare Power BI-elementtyper.
  • Importer: Du kan publisere støttede elementer ved hjelp av REST-API-ene for Power BI for å importere en gyldig kildefil til et arbeidsområde (for eksempel en PBIX-fil).
  • Distribuer: Du kan distribuere støttede elementer, og promotere dem fra ett arbeidsområde til et annet hvis de er faser i et utrullingssamlebånd.
• FABRIC REST API-er: Det finnes forskjellige FABRIC REST API-endepunkter som du kan bruke til å distribuere innhold. Fabric REST API-er støtter både Power BI- og Fabric-elementtyper.
  • Opprett: Du kan opprette støttede elementer ved hjelp av FABRIC REST API-er sammen med en gyldig elementdefinisjon.
  • Oppdater fra Git: Du kan oppdatere et arbeidsområde med innhold fra et eksternt repositorium som er koblet til ved hjelp av Git-integrering.
• XMLA-lese-/skriveendepunkter: Du kan opprette eller endre semantiske modeller ved å bruke XMLA-endepunkter sammen med en gyldig model.bim-fil. MED XMLA-endepunkter kan du distribuere endringer til bestemte modellobjekter i stedet for hele modellen. Azure Pipelines kan bruke tredjepartsverktøy (for eksempel kommandolinjegrensesnittet i Tabellredigering) til å distribuere semantiske modeller ved hjelp av XMLA-endepunktene.

Tips

Når du bruker FABRIC- eller Power BI REST-API-ene, må du først opprette en appregistrering i Azure (beskrevet her for Power BI Embedded). Dette krever en Microsoft Entra ID-leier og en organisasjonsbruker, og kan være en kompleks prosess for å konfigurere de riktige tillatelsene. Du kan imidlertid utføre REST-API-ene for stoff i notatblokker uten å opprette en appregistrering. Dette effektiviserer konfigurasjonen og bruken av API-er i løsningene dine, slik at du ikke trenger å administrere legitimasjon eller konfigurere et oppsett før du bruker API-ene.

Hvis du vil bruke FABRIC REST-API-er uten å registrere en app, kan du bruke semantisk kobling i en Fabric-notatblokk med FabricRestClientClass av sempy til å kalle API-en.

Sammen med automatisert testing hjelper Azure Pipelines-integrering med Power BI deg med å oppnå kontinuerlig integrering og kontinuerlig distribusjon (CI/CD).

Når du bruker Azure Pipelines, kan pipeline-eiere tilpasse utløsere, trinn og funksjonalitet for å dekke distribusjonsbehov. Som sådan varierer antall og typer datasamlebånd avhengig av løsningskravene.

Det finnes tre typer Azure Pipelines som du kan konfigurere til å teste, administrere og distribuere Power BI-løsningen.

• Valideringssamlebånd
• Bygge datasamlebånd
• Frigi datasamlebånd

Notat

Det er ikke nødvendig å ha alle tre typer datasamlebånd i publiseringsløsningen. Avhengig av arbeidsflyt og behov kan du konfigurere én eller flere av variantene av datasamlebåndet som er beskrevet i denne artikkelen, til å automatisere innholdspublikasjonen. Denne muligheten til å tilpasse datasamlebånd er en fordel med Azure Pipelines i forhold til de innebygde utrullingssamlebåndene for stoff.

Valideringssamlebånd

Valideringssamlebånd utfører grunnleggende kvalitetskontroller av datamodeller før de publiseres til et arbeidsområde for utvikling. Vanligvis utløser endringer i en gren av det eksterne repositoriet datasamlebåndet for å validere disse endringene med automatisert testing.

Eksempler på automatisert testing inkluderer skanning av datamodellen for brudd på anbefalte fremgangsmåter ved hjelp av beste praksisanalyse (BPA), eller ved å kjøre DAX-spørringer mot en publisert semantisk modell. Resultatene av disse testene lagres deretter i det eksterne repositoriet for dokumentasjon og overvåkingsformål. Datamodeller som ikke kan valideres, bør ikke publiseres. I stedet bør datasamlebåndet varsle innholdsopprettere om problemene.

Bygge datasamlebånd

Bygge datasamlebånd klargjøre datamodeller for publisering til Power BI-tjenesten. Disse datasamlebåndene kombinerer serialiserte modellmetadata til én enkelt fil som senere publiseres av et utgivelsessamlebånd. Et byggforløp kan også gjøre endringer i metadataene, for eksempel endre parameterverdier. Byggesamlebånd produserer distribusjonsartefakter som består av datamodellmetadata (for datamodeller) og Power BI-prosjektfiler (PBIP) som er klare for publisering til Power BI-tjenesten.

Frigi datasamlebånd

Frigi datasamlebånd publiserer eller distribuerer innhold. En publiseringsløsning inkluderer vanligvis flere utgivelsessamlebånd, avhengig av målmiljøet.

• utgivelsesforløp for utvikling: Dette første datasamlebåndet utløses automatisk. Den publiserer innhold til et arbeidsområde for utvikling etter at bygg- og valideringssamlebåndet er fullført.
• test- og produksjonsutgivelsessamlebånd: Disse datasamlebåndene utløses ikke automatisk. I stedet utløses de ved behov eller når de godkjennes. Test- og produksjonsutgivelsessamlebånd distribuerer innhold til henholdsvis et test- eller produksjonsarbeidsområde etter utgivelsesgodkjenning. utgivelsesgodkjenninger sikre at innholdet ikke distribueres automatisk til en test- eller produksjonsfase før det er klart. Disse godkjenningene leveres av utgivelsesledere, som er ansvarlige for planlegging og koordinering av innholdsutgivelser for å teste og produksjonsmiljøer.

Bestem hvordan du skal heve innhold mellom arbeidsområder

Når du bruker ulike miljøer for utvikling, test og produksjon, må du distribuere innhold til alle tre miljøene. Det finnes ulike verktøy og fremgangsmåter du kan ta for å fremme innhold mellom arbeidsområder, avhengig av den bestemte arbeidsflyten og behovene dine.

Avsnittene nedenfor beskriver fremgangsmåter du kan ta for å heve innhold mellom arbeidsområder.

Forsiktighet

Unngå manuelt publisering av innhold fra den lokale maskinen for å teste og produksjonsarbeidsområder. Det kan føre til feil eller forstyrrelser på grunn av feil. Vanligvis bør du bare publisere til et arbeidsområde for utvikling, eller til et privat arbeidsområde hvis du bruker et.

Distribuer med datasamlebånd for stoffdistribusjon

Med utrullingssamlebånd kan du konfigurere to eller flere faser (for eksempel utvikling, test eller produksjon) og distribuere stoffinnhold mellom disse fasene. En pipeline-administrator tilordner ett enkelt Power BI-arbeidsområde til hvert trinn i utrullingsforløpet. Hvordan du bruker datasamlebånd for distribusjon, avhenger av hvordan du har bestemt deg for å konfigurere og bruke arbeidsområder.

Vurder å bruke utrullingssamlebånd når:

• Innhold distribueres til arbeidsområder med lisensmodus for PPU- eller Premium-kapasitet eller Stoffkapasitet.
• Innholdselementtyper og scenarioer støttes av utrullingssamlebånd.

Vurder en annen tilnærming enn utrullingssamlebånd når:

• Du foretrekker å distribuere innhold fra et eksternt repositorium, for eksempel ved hjelp av Azure Pipelines.
• Du har tenkt å bruke Git-integrering til å synkronisere ulike faser med ulike grener av det eksterne repositoriet, i stedet for å distribuere innholdet.

Tips

Hvis du vil ha mer informasjon om hvordan du bruker utrullingssamlebånd til å heve innhold mellom arbeidsområder, kan du se selvbetjent innholdspublisering og virksomhetsinnholdspublisering bruksscenarioer.

Hvis du vil ha mer informasjon om utrullingssamlebånd, kan du se Utrullingssamlebånd: Forstå distribusjonsprosessen.

Den enkleste måten å bruke et utrullingssamlebånd på, er når du publiserer alt innhold til ett enkelt arbeidsområde og promoterer det til senere faser i et enkelt utrullingssamlebånd. Diagrammet nedenfor viser denne første fremgangsmåten for å distribuere innhold ved hjelp av et utrullingssamlebånd.

Sammendrag publiserer en innholdsoppretter vanligvis først innhold til den første fasen av datasamlebåndet. Deretter utløser en pipelineadministrator en distribusjon for å heve innhold til de senere fasene. Når en distribusjon oppstår, distribuerer utrullingssamlebåndet innholdsmetadata fra ett arbeidsområde til det neste.

Når du skiller innhold etter elementtype i forskjellige arbeidsområder, bruker du separate utrullingssamlebånd til å distribuere dette innholdet. Du kan koble innhold på tvers av arbeidsområder med flere datasamlebånd for distribusjon ved hjelp av automatisk binding. Automatisk binding på tvers av utrullingssamlebånd sikrer at innholdet forblir koblet til det aktuelle elementet i det respektive stadiet. Rapporten i utviklingsfasen vil for eksempel forbli knyttet til modellen i utviklingsfasen av det andre utrullingsforløpet. Du kan imidlertid også unngå automatisk binding virkemåte hvis scenarioet krever at du kobler innhold på tvers av arbeidsområder med et annet mønster.

Diagrammet nedenfor viser denne andre fremgangsmåten for å distribuere innhold ved hjelp av flere utrullingssamlebånd.

I sammendraget er distribusjon av innhold ved hjelp av flere utrullingssamlebånd lik ved hjelp av ett enkelt datasamlebånd. En viktig forskjell er at du eventuelt kan koble til innhold som er koblet til på tvers av arbeidsområder og utrullingssamlebånd ved hjelp av automatisk binding. Ellers er det identisk med den første tilnærmingen.

Utrullingssamlebånd er et fleksibelt og enkelt verktøy som passer for å forbedre behandling av innholdslivssyklus for både selvbetjente og virksomhetsscenarioer.

Tilgang til både arbeidsområdet og utrullingssamlebåndet kreves for brukerne som utfører en distribusjon. Vi anbefaler at du tilgang til datasamlebånd for plandistribusjon, slik at administratorer for datasamlebånd kan vise distribusjonslogg og sammenligne innhold. Når du samarbeider med flere innholdsopprettere, bør du vurdere å begrense datasamlebåndtilgang til utgivelsesledere eller tekniske eiere som er best egnet til å overvåke distribusjons- og utgivelsesprosessene.

Vurder i tillegg å bruke distribusjonsregler for å angi ulike konfigurasjoner for elementer i ulike faser. Det kan for eksempel hende du vil at en semantisk modell i utviklingsarbeidsområdet skal hente data fra utviklingsdatabasen, mens den semantiske modellen i produksjonsarbeidsområdet henter data fra produksjonsdatabasen.

Tips

Hvis flere personer har tilgang til datasamlebåndet for distribusjon, anbefaler vi at du ser gjennom distribusjonsloggen regelmessig. Disse vurderingene kan hjelpe deg med å identifisere ikke-godkjente distribusjoner eller distribusjonsfeil.

Hvis du bruker automatisk binding til å koble elementer på tvers av utrullingssamlebånd, må du kontrollere at du også ser gjennom elementavstamminger for å identifisere pauser i automatisk binding forårsaket av at noen publiserer koblet innhold til feil stadium.

Du kan utløse distribusjoner manuelt eller programmatisk ved hjelp av REST-API-er for Power BI. I begge tilfeller bør du definere en klar og robust prosess om når du forfremmer innhold til hvert trinn, og hvordan du ruller tilbake utilsiktede endringer.

Utføre distribusjon manuelt

Du kan distribuere innhold manuelt ved hjelp av datasamlebåndet for stoffdistribusjon. Du kan velge distribuere alt innhold eller velge elementer. Selektiv distribusjon kan være nyttig når noe innhold er klart til å flyttes til neste fase, men noen elementer gjennomgår fortsatt utvikling eller validering. I tillegg kan du utføre en bakoverdistribusjon når innholdsendringer finnes i et senere stadium, men ikke i en tidligere.

Forsiktighet

Når du bruker utrullingssamlebånd, anbefaler vi at du distribuerer innhold i én retning, for eksempel fra utvikling til test til produksjonsarbeidsområder. Vanligvis bør du unngå å gjøre endringer i innhold i senere faser før disse endringene har gjennomgått riktig validering i utvikling eller test.

Når du utfører en manuell distribusjon, kan du sammenligne faser for å identifisere innholdsendringer i endre gjennomgang vinduet. Denne fremgangsmåten er spesielt nyttig når du ikke bruker et Git-eksternt repositorium for kildekontroll.

Bruk REST-API-ene for Power BI til å utføre distribusjon

Du kan bruke REST-API-ene for Power BI til å distribuere innhold ved hjelp av en utrullingssamlebånd. En fordel med å bruke REST-API-ene er at du kan automatisere distribusjon og integrere den med andre verktøy, for eksempel Azure Pipelines i Azure DevOps.

Distribuer med Azure Pipelines

Med Azure Pipelines kan du organisere distribusjon mellom alle faser. Med denne fremgangsmåten bruker du FABRIC REST-API-ene til å distribuere og administrere innhold, slik at du kan bruke forskjellige Azure Pipelines, for eksempel validerings- og utgivelsessamlebånd.

Vurder å bruke Azure Pipelines når:

• Du vil sentralisere orkestrering av distribusjon fra Azure DevOps.
• Innholdsopprettere bruker Azure DevOps til å samarbeide og for kildekontroll.

Vurder en annen tilnærming enn Azure Pipelines når:

• Innholdsopprettere er ikke kjent med Azure DevOps eller kodebaserte distribusjoner.
• Innhold inneholder elementtyper som ikke har et støttet definisjons- eller kildefilformat, for eksempel instrumentbord.

Det finnes to ulike fremgangsmåter for å distribuere innhold med Azure Pipelines. De orkestrerer distribusjonssamlebånd, eller de distribuerer innhold til et arbeidsområde uten et utrullingssamlebånd.

Orchestrate Fabric-distribusjonssamlebånd ved hjelp av Azure Pipelines

I denne fremgangsmåten orkestrerer utgivelsessamlebånd innholdsdistribusjon for å teste og produksjonsarbeidsområder ved hjelp av utrullingssamlebånd. Innhold fremmes gjennom utviklings-, test- og produksjonsarbeidsområder i Fabric.

Diagrammet nedenfor viser hvordan du orkestrerer utrullingssamlebånd fra Azure Pipelines.

Sammendrag publiserer innholdsopprettere innhold til arbeidsområdet i den første fasen av utrullingsforløpet. Deretter godkjenner en utgivelsesbehandling distribusjonen, som utløser en Azure Pipeline. Dette datasamlebåndet bruker REST-API-ene for Power BI til å heve innhold mellom faser, slik at metadataene distribueres til et annet arbeidsområde. En fordel med denne fremgangsmåten er at du kan orkestrere distribusjon av flere stoffelementtyper gjennom utrullingssamlebånd, fordi enkelte elementtyper er utviklet i Fabric-portalen og dermed ikke kan distribueres av Azure Pipelines alene.

Distribuer innhold ved hjelp av bare Azure Pipelines

Du kan også distribuere innhold til et arbeidsområde fra Azure DevOps ved hjelp av Azure Pipelines. Denne fremgangsmåten bruker ikke utrullingssamlebånd. I stedet bruker den utgivelsessamlebånd til å distribuere kildefiler eller metadatafiler ved hjelp av enten Fabric- eller Power BI REST-API-er eller XMLA-lese-/skriveendepunkter. Vanligvis lagres disse filene i et Azure Repos Git-repositorium.

Diagrammet nedenfor viser hvordan du distribuerer innhold ved hjelp av bare Azure Pipelines.

I sammendraget utfører og sender innholdsopprettere innholdsendringer til et eksternt Git-repositorium i Azure Repos. Dette innholdet brukes av Azure Pipelines for distribusjonen. Når versjonsbehandlingen godkjenner den spesifikke distribusjonen, distribuerer Azure Pipeline innhold til arbeidsområdet, enten ved hjelp av REST-API-ene for Power BI (det vil eksempelvis for PBIX-filer), FABRIC REST-API-ene (det vil eksempelvis for elementdefinisjoner) eller XMLA-endepunkter (det vil eksempelvis for model.bim-filer). Det finnes en egen Azure Pipeline for hvert arbeidsområde.

Denne fremgangsmåten krever ikke stoffkapasitet eller Premium-lisensiering når du publiserer bare Power BI Desktop-filer med REST-API-ene for Power BI. Det innebærer imidlertid mer konfigurasjonsinnsats og kompleksitet fordi du må administrere distribusjon utenfor Power BI. Utviklingsteam som allerede bruker DevOps for dataløsninger utenfor Power BI, kan være kjent med denne fremgangsmåten. Utviklingsteam som bruker denne tilnærmingen, kan konsolidere distribusjon av dataløsninger i Azure DevOps.

Distribuer med Fabric Git-integrasjon

Når du bruker Git-integrering, kan du synkronisere forskjellige grener til forskjellige arbeidsområder i stedet for å publisere eller distribuere innhold eksplisitt. På den måten kan du ha separate grener for utviklings-, test- og produksjonsarbeidsområder. I dette scenarioet synkroniseres hovedgrenen med produksjon arbeidsområde. Deretter distribuerer du innhold mellom arbeidsområder ved å utføre en pull-forespørsel om å slå sammen utviklingsgrenen til testgrenen (for å distribuere til testarbeidsområdet) eller slå sammen testgrenen til hovedgrenen (for å distribuere til produksjonsarbeidsområdet).

Diagrammet nedenfor viser hvordan du distribuerer innhold ved hjelp av Fabric Git-integrering for å synkronisere grener til ulike arbeidsområder. Diagrammet inneholder ikke detaljer om forgrening eller fletting av innhold for enkelhet.

I sammendraget utfører og sender innholdsopprettere innholdsendringer til et eksternt Git-repositorium i Azure Repos. Innholdsopprettere åpner pull-forespørsler (PR-er) for å be om å slå sammen endringene til en bestemt gren. Avhengig av forgreningsstrategien er ulike grener koblet til ulike arbeidsområder. Når endringene er slått sammen til en gren, synkroniserer innholdsopprettere arbeidsområdet med det eksterne Git-repositoriet for å vise de siste endringene i innholdet i arbeidsområdet.

Vurder denne tilnærmingen når:

• Du vil organisere distribusjon mellom arbeidsområder ved hjelp av forgrenings- og sammenslåingsstrategien.
• Du har ikke tenkt å bruke Azure Pipelines eller Fabric-distribusjonssamlebånd til å organisere distribusjoner for testing og produksjon.
• Arbeidsområdet inneholder ikke elementer som ikke støttes eller scenarioer.
• Innhold har ikke følsomhetsetiketter.

Notat

Det finnes mange gyldige måter å distribuere innhold på. Du kan for eksempel bruke en kombinasjon av de ulike fremgangsmåtene som beskrives i denne artikkelen.

Du kan for eksempel distribuere innhold til et arbeidsområde for utvikling ved hjelp av en Azure Pipeline, som gjør at du kan dra nytte av kontinuerlige integreringsfunksjoner og utføre automatisert testing (for eksempel ved hjelp av Best Practice Analyzer). Deretter kan du distribuere innhold mellom arbeidsområder ved hjelp av git-integrasjon eller et stoffdistribusjonssamlebånd.

Velg fremgangsmåten som passer best til dine behov og måten teamet fungerer på.

Bestem hvordan du skal håndtere aktiviteter etter distribusjon

Etter distribusjon er det ulike aktiviteter etter distribusjon som må håndteres. Mange av disse aktivitetene kan håndteres programmatisk, for eksempel av en Azure Pipeline eller notatblokk og REST-API-ene for Power BI og Fabric. Du kan for eksempel programmatisk angi legitimasjon for datakilder, administrere planlagt oppdatering og utløse oppdateringer etter en metadatadistribusjon. Noen oppgaver krever imidlertid manuell inngripen, for eksempel et førstegangsoppsett eller oppdatering av en Power BI-app.

Kontroller at du identifiserer alle relevante aktiviteter etter distribusjon for innholdet, og at du bestemmer hvordan de skal håndteres.

Når du har planlagt hvordan du skal distribuere innhold, bør du vurdere hvordan du skal støtte og overvåke det.

sjekkliste – Når du planlegger hvordan du distribuerer innhold, omfatter viktige beslutninger og handlinger:

• Identifiser distribusjonsalternativene som er tilgjengelige for deg: Avhengig av lisensiering og innhold har du ulike alternativer for publisering av innhold eller promotering mellom arbeidsområder. Identifiser om du kan bruke utrullingssamlebånd, Azure DevOps, Git-integrasjon, Fabric REST API-er og XMLA-lese-/skriveendepunkter.
• Bestem hvordan du publiserer innhold: Velg en fremgangsmåte for å publisere innhold som passer best til arbeidsflyten og behovene dine. Sørg for at denne tilnærmingen samsvarer med de andre strategiene dine, for eksempel hvordan du sporer og administrerer endringer.
• Bestem hvordan du skal heve innhold mellom arbeidsområder: Velg en fremgangsmåte for å distribuere innhold fra utvikling til testarbeidsområder og fra test til produksjonsarbeidsområder. Sørg for at denne tilnærmingen samsvarer med de andre strategiene dine, for eksempel hvordan du publiserer innhold.
• Planlegge utgivelsesstrategien: Bestem om en bestemt person vil være ansvarlig for den endelige gjennomgangen av innhold før du godkjenner en utgivelse eller distribusjon. Sørg for at denne personen er klar over denne oppgaven og hva de bør gjøre for å beskytte distribusjonsprosessen uten å blokkere fremdriften.
• Planlegge aktiviteter etter distribusjon: Kontroller at du har bestemt deg for en prosess for å utføre aktiviteter som å oppdatere en Power BI-app eller oppdatere dataelementer etter en metadatadistribusjon. Vurder å automatisere denne prosessen ved hjelp av FABRIC REST API-er.
• Utføre førstegangsoppsett av distribusjonsverktøy og prosesser: Sørg for at du konfigurerer riktig tilgang, og at tillatelsene samsvarer med hvordan du konfigurerer tilgang til innholdet.
• Distribuer innhold til produksjon: Når du har planlagt og konfigurert distribusjonen, distribuerer du innhold til produksjon.

Relatert innhold

I den neste artikkelen i denne serienlærer du hvordan du støtter og overvåker innhold som en del av administrasjonen av innholdslivssyklusen.