Power BI-bruksscenarioer: Virksomhetsinnholdspublisering

Merk

Denne artikkelen er en del av planleggingsserien for power BI-implementering av artikler. Denne serien fokuserer hovedsakelig på Power BI-arbeidsbelastningen i Microsoft Fabric. Hvis du vil ha en innføring i serien, kan du se Planlegging av Power BI-implementering.

Når innholdsopprettere samarbeider for å levere analytiske løsninger som er viktige for organisasjonen, må de sikre rettidig og pålitelig levering av innhold til forbrukerne. Tekniske team løser denne utfordringen ved hjelp av en prosess kalt DevOps. DevOps gjør det mulig for team å automatisere og skalere prosesser ved å ta i bruk praksiser som forbedrer og akselererer leveringen.

Merk

Datateam som løser de samme utfordringene, kan også øve på DataOps. DataOps bygger på DevOps-prinsipper, men DataOps inkluderer flere praksiser som er spesifikke for databehandling, for eksempel datakvalitetssikring og styring. Vi refererer til DevOps i denne artikkelen, men vær oppmerksom på at de underliggende prinsippene også kan gjelde for DataOps.

Innholdsopprettere og forbrukere drar nytte av flere fordeler når de tar i bruk DevOps-praksis for å publisere Power BI-innhold. Følgende punkter er en oversikt på høyt nivå over hvordan denne prosessen fungerer.

1. Utvikle innhold og utfør arbeid til et eksternt repositorium: Innholdsopprettere utvikler løsningen sin på sin egen maskin. De forplikter seg og lagrer arbeidet sitt i et eksternt repositorium med jevne mellomrom under utvikling. Et eksternt repositorium inneholder den nyeste versjonen av løsningen, og den er tilgjengelig for hele utviklingsteamet.
2. Samarbeid og administrer innholdsendringer ved hjelp av versjonskontroll: Andre innholdsopprettere kan foreta endringer i løsningen ved å opprette en gren. En gren er en kopi av et eksternt repositorium. Når disse revisjonene er klare og godkjent, slås grenen sammen med den nyeste versjonen av løsningen. Alle revisjoner av løsningen spores. Denne prosessen kalles versjonskontroll (eller kildekontroll).
3. Distribuer og hev innhold ved hjelp av datasamlebånd: I det selvbetjente bruksscenarioet for innholdspublisering fremmes innhold (eller distribueres) gjennom utviklings-, test- og produksjonsarbeidsområder ved hjelp av datasamlebånd for Power BI-distribusjon. Datasamlebånd for Power BI-distribusjon kan forfremme innhold til Power BI Premium-arbeidsområder manuelt ved hjelp av brukergrensesnittet, eller programmatisk ved hjelp av REST-API-ene. Bedriftsinnholdspublisering (fokus for dette bruksscenarioet) fremmer derimot innhold ved hjelp av Azure Pipelines. Azure Pipelines er en Azure DevOps-tjeneste som automatiserer testing, administrasjon og distribusjon av innhold ved hjelp av en rekke tilpassede, programmatiske trinn. I bruksscenarioet for virksomhetsinnholdspublisering kan disse datasamlebåndene også refereres til som kontinuerlige integrasjons- og distribusjonsforløp (eller CI/CD). Disse datasamlebåndene integrerer ofte og integrerer endringer automatisk og effektiviserer innholdspublisering.

Viktig

Til tider refererer denne artikkelen til Power BI Premium eller dets kapasitetsabonnementer (P SKU-er). Vær oppmerksom på at Microsoft for øyeblikket konsoliderer kjøpsalternativer og trekker tilbake Power BI Premium per kapasitet sKU-er. Nye og eksisterende kunder bør vurdere å kjøpe Fabric-kapasitetsabonnementer (F SKU-er) i stedet.

Hvis du vil ha mer informasjon, kan du se Viktige oppdateringer som kommer til Power BI Premium-lisensiering og vanlige spørsmål om Power BI Premium.

DevOps støtter en moden, systematisk tilnærming til innholdsbehandling og publisering. Det gjør det mulig for innholdsopprettere å samarbeide om løsninger, og det sikrer rask og pålitelig levering av innhold til forbrukerne. Når du overholder DevOps-praksis, drar du nytte av strømlinjeformede arbeidsflyter, færre feil og forbedrede opplevelser for innholdsopprettere og innholdsforbrukere.

Du konfigurerer og administrerer DevOps-praksiser for Power BI-løsningen ved hjelp av Azure DevOps. I bedriftsscenarioer kan du automatisere innholdspublikasjonen med Azure DevOps og REST-API-ene for Power BI på tre forskjellige måter.

• Rest-API-er for Power BI med datasamlebånd for Power BI-distribusjon: Du kan importere innhold til utviklingsarbeidsområder og bruke utrullingssamlebånd til å distribuere innhold gjennom test- og produksjonsarbeidsområder. Du kontrollerer fortsatt distribusjon fra Azure DevOps, og bruker REST-API-ene for Power BI til å administrere utrullingssamlebånd i stedet for individuelle innholdselementer. I tillegg bruker du XMLA-endepunktet til å distribuere metadata for datamodell i stedet for en Power BI Desktop-fil (PBIX) med Azure DevOps. Med disse metadataene kan du spore endringer på objektnivå ved hjelp av versjonskontroll. Selv om det er mer robust og enklere å vedlikeholde, krever denne tilnærmingen Premium-lisensiering og moderat skriptingsinnsats for å konfigurere innholdsimport og distribusjon med REST-API-ene for Power BI. Bruk denne fremgangsmåten når du vil forenkle behandling av innholdslivssyklus med utrullingssamlebånd, og du har en Premium-lisens. XMLA-endepunktet og Power BI-distribusjonssamlebånd er Premium-funksjoner.
• REST-API-er for Power BI: Du kan også importere innhold til utviklings-, test- og produksjonsarbeidsområder ved hjelp av Azure DevOps og bare REST-API-er for Power BI. Denne fremgangsmåten krever ikke Premium-lisensiering, men det innebærer høy skriptingsinnsats og oppsett, fordi distribusjon administreres utenfor Power BI. Bruk denne fremgangsmåten når du vil distribuere Power BI-innhold sentralt fra Azure DevOps, eller når du ikke har en Premium-lisens. Hvis du vil ha en visuell sammenligning mellom de to første tilnærmingene, kan du se flytskjemaet for utgivelsesforløp.
• Power BI-automatiseringsverktøy med Power BI-utrullingssamlebånd: Du kan bruke Power BI-automatiseringsverktøyene Azure DevOps-utvidelsen til å administrere utrullingssamlebånd i stedet for REST-API-ene for Power BI. Denne fremgangsmåten er et alternativ til det første alternativet, som bruker REST-API-ene for Power BI med datasamlebånd for Power BI-distribusjon. Utvidelsen for automatiseringsverktøy i Power BI er et åpen kilde verktøy. Det hjelper deg med å administrere og publisere innhold fra Azure DevOps uten å måtte skrive PowerShell-skript. Bruk denne fremgangsmåten når du vil administrere utrullingssamlebånd fra Azure DevOps med minimal skripting, og du har en Premium-kapasitet.

Denne artikkelen fokuserer på det første alternativet, som bruker REST-API-ene for Power BI med utrullingssamlebånd for Power BI. Den beskriver hvordan du kan bruke Azure DevOps til å konfigurere Fremgangsmåter for DevOps. Den beskriver også hvordan du kan bruke Azure Repos for eksterne repositorier og automatisere innholdstesting, integrering og levering med Azure Pipelines. Azure DevOps er ikke den eneste måten å konfigurere publisering av bedriftsinnhold på, men enkel integrering med Power BI gjør det til et godt valg.

Merk

Dette bruksscenarioet er ett av scenarioene for innholdsbehandling og distribusjon . For kortfattethet dekkes ikke noen aspekter som er beskrevet i emnet innholdssamarbeid og leveringsscenarioer i denne artikkelen. Hvis du vil ha fullstendig dekning, kan du lese disse artiklene først.

Tips

Microsoft Fabric tilbyr andre alternativer for publisering av bedriftsinnhold ved hjelp av Fabric Git-integrasjon. Med Git-integrering kan du koble et Fabric-arbeidsområde til en gren i azure Repos eksternt repositorium. Innhold som er lagret i denne grenen, synkroniseres automatisk til arbeidsområdet, som om innholdet ble publisert til arbeidsområdet. Derimot kan innholdsopprettere utføre og sende endringer fra Fabric-arbeidsområdet til det eksterne repositoriet.

Git-integrering kan effektivisere samarbeid og innholdspublisering, men det krever mer planlegging for hvordan du skal bruke Fabric-arbeidsområder og hva forgreningsstrategien din er. Hvis du vil ha mer informasjon om hvordan du kan konfigurere og bruke Fabric Git-integrering, kan du se Komme i gang med Git-integrasjon eller opplæring: Administrasjon av slutt på livssyklus.

Scenariodiagram

Diagrammet nedenfor viser en oversikt på høyt nivå over de vanligste brukerhandlingene og Power BI-komponentene som støtter bedriftsinnholdspublisering. Fokuset er på bruk av Azure DevOps til å administrere og publisere innhold programmatisk gjennom utviklings-, test- og produksjonsarbeidsområder i Power Bi-tjeneste.

Tips

Vi oppfordrer deg til å laste ned scenariodiagrammet hvis du vil bygge det inn i presentasjonen, dokumentasjonen eller blogginnlegget, eller skrive det ut som en veggplakat. Fordi det er et SVG-bilde (Scalable Vector Graphics), kan du skalere det opp eller ned uten tap av kvalitet.

Scenariodiagrammet viser følgende brukerhandlinger, prosesser og funksjoner.

Vare	Beskrivelse
	Innholdsopprettere utvikler datamodeller ved hjelp av Power BI Desktop eller Tabellredigering, og de utvikler rapporter ved hjelp av Power BI Desktop. Innholdsopprettere lagrer arbeidet sitt i et lokalt repositorium under utvikling.
	Innholdsopprettere kan klone et eksternt repositorium for å få en lokal kopi av innholdet.
	Noen datakilder kan kreve en lokal datagateway eller VNet-gateway for dataoppdatering, for eksempel de som befinner seg i et privat organisasjonsnettverk.
	Innholdsopprettere utfører regelmessig og sender endringene sine til et eksternt repositorium under utvikling ved hjelp av en Git-klient, for eksempel Visual Studio Code. I diagrammet er det eksterne repositoriet Azure Repos.
	Andre innholdsopprettere bruker Azure Repos til å spore endringer med versjonskontroll. De samarbeider ved å forplikte endringer i separate grener.
	Endringer i innhold i det eksterne repositoriet utløser Azure Pipelines. Et valideringssamlebånd er det første datasamlebåndet som utløses. Valideringssamlebåndet utfører automatiserte tester for å validere innhold før det publiseres.
	Innhold som passerer valideringssamlebåndet utløser et etterfølgende byggforløp. Byggeforløpet klargjør innhold for publisering til Power Bi-tjeneste. Prosessen frem til dette punktet kalles vanligvis kontinuerlig integrasjon (CI).
	Innhold publiseres og distribueres ved hjelp av utgivelsessamlebånd. Utgivelsessamlebåndene bruker enten REST-API-ene for Power BI eller XMLA-endepunktet for arbeidsområdet til å importere innhold programmatisk til Power Bi-tjeneste. Distribusjon ved hjelp av utgivelsessamlebånd kalles vanligvis kontinuerlig distribusjon (CD).
	En utgivelsesbehandling kontrollerer distribusjon for å teste og produksjonsarbeidsområder ved hjelp av en utgivelsesgodkjenning for Azure Pipelines. I virksomhetsinnholdspublisering planlegger og koordinerer en utgivelsesbehandling vanligvis innholdsutgivelsen for å teste og produksjonsmiljøer. De koordinerer og kommuniserer med innholdsopprettere, interessenter og brukere.
	Et utgivelsesforløp publiserer innhold til utviklingsarbeidsområdet, eller hever innhold fra utvikling til testarbeidsområder, eller test til produksjonsarbeidsområder.
	Innholdsopprettere som arbeider i et arbeidsområde som har lisensmodus for Fabric-kapasitet , kan bruke Git-integrering. Med Git-integrering kan innholdsopprettere arbeide i et privat arbeidsområde under utvikling. Innholdsoppretteren synkroniserer en ekstern gren (vanligvis en bestemt funksjonsgren eller en feilgren) fra Azure Repos til deres private arbeidsområde. Innholdsendringer synkroniseres mellom den eksterne grenen i Azure Repos og arbeidsområdet. I dette scenarioet trenger ikke innholdsopprettere å bruke Azure Pipelines til å publisere innhold. Innholdsopprettere kan også regelmessig utføre og sende endringer fra arbeidsområdet etter publisering. Når de er klare, kan innholdsopprettere foreta en pull-forespørsel (PR) for å slå sammen endringene i hovedgrenen.
	Når du bruker Git-integrering, synkroniseres arbeidsområdet for utvikling med hovedgrenen for å få de nyeste versjonene av innholdet. Dette innholdet inneholder alle endringer fra pull-forespørsler som en utgivelsesbehandling gjennomgår, godkjenner og fletter.
	Arbeidsområder er satt til Fabric-kapasitet, Premium-kapasitet, Premium per bruker- eller Embedded-lisensmodus, for å tillate bruk av datasamlebånd for Power BI-distribusjon og XMLA-lese-/skriveendepunktet.
	En administrator for utrullingssamlebånd konfigurerer utrullingssamlebåndet for Power BI med tre faser: utvikling, test og produksjon. Hvert trinn justeres til et eget arbeidsområde i Power Bi-tjeneste. Distribusjonsinnstillinger og -tilgang er angitt for utrullingssamlebåndet.
	Utviklingsarbeidsområdet inneholder de nyeste versjonene av innhold, inkludert alle godkjente og flettede endringer. Når det er godkjent, distribuerer et utgivelsessamlebånd innhold fra utviklingen til testarbeidsområdet.
	Korrekturlesere i testarbeidsområdet utfører testing og kvalitetssikring på innhold. Når det er godkjent, distribuerer et utgivelsessamlebånd innhold fra testen til produksjonsarbeidsområdet. Når du bruker Git-integrasjon med utrullingssamlebånd, synkroniseres ikke testarbeidsområdet med noen gren.
	Når utrullingssamlebåndet er fullført, utfører innholdsopprettere manuelt aktiviteter etter distribusjon. Aktiviteter kan omfatte konfigurasjon av planlagt dataoppdatering eller oppdatering av en Power BI-app for produksjonsarbeidsområdet. Når du bruker Git-integrasjon med utrullingssamlebånd, synkroniseres ikke produksjonsarbeidsområdet med noen gren.
	Innholdslesere får tilgang til innholdet ved hjelp av produksjonsarbeidsområdet eller en Power BI-app.

Tips

Vi anbefaler at du også ser gjennom selvbetjent innholdspublisering og avanserte bruksscenarioer for datamodellbehandling . Bruksscenarioet for publisering av virksomhetsinnhold bygger på konsepter som disse scenarioene introduserer.

Viktige punkter

Nedenfor finner du noen viktige punkter for å fremheve om publiseringsscenarioet for virksomhetsinnhold.

Versjonskontroll

Sporing av endringer i innholdslivssyklusen er viktig for å sikre stabil og konsekvent levering av innhold til forbrukerne. I dette bruksscenarioet administrerer innholdsopprettere og eiere innholdsendringer i et eksternt repositorium ved hjelp av versjonskontroll. Versjonskontroll er praksisen med å administrere endringer i filer eller kode i et sentralt repositorium. Denne praksisen gir bedre samarbeid og effektiv administrasjon av versjonsloggen. Versjonskontroll har fordeler for innholdsopprettere, inkludert muligheten til å rulle tilbake eller slå sammen endringer.

Innholdsopprettere utvikler vanligvis datamodeller i Tabellredigering for å støtte bedre versjonskontroll. I motsetning til en datamodell du utvikler i Power BI Desktop, lagres en datamodell utviklet i Tabellredigering i metadataformat som kan leses av mennesker. Dette formatet aktiverer versjonskontroll på objektnivå for datamodell. Du bør bruke versjonskontroll på objektnivå når du samarbeider med flere personer på samme datamodell. Hvis du vil ha mer informasjon, kan du se det avanserte bruksscenarioet for datamodellbehandling . Det er ikke mulig å se endringer du har gjort i en Power BI Desktop-fil (PBIX), for eksempel rapportdefinisjonen eller datamodellen. Du kan for eksempel ikke spore endringer på en rapportside, for eksempel visualobjektene som brukes, plasseringene deres og felttilordningene eller formateringen.

Innholdsopprettere lagrer metadatafiler for datamodell og PBIX-filer i et sentralt eksternt repositorium, for eksempel Azure Repos. Disse filene kuratert av en teknisk eier. Selv om en innholdsoppretter utvikler en løsning, er en teknisk eier ansvarlig for å administrere løsningen og se gjennom endringene og slå dem sammen til én enkelt løsning. Azure Repos tilbyr avanserte alternativer for sporing og administrasjon av endringer. Denne fremgangsmåten skiller seg fra fremgangsmåten som er beskrevet i det selvbetjente bruksscenarioet for innholdspublisering , der oppretteren bruker OneDrive-lagringsplass med versjonssporing. Det er viktig å opprettholde et godt kuratert, dokumentert repositorium fordi det er grunnlaget for alt innhold og samarbeid.

Her er noen viktige hensyn for å hjelpe deg med å konfigurere et eksternt repositorium for versjonskontroll.

• Omfang: Definer tydelig omfanget av repositoriet. Ideelt sett er omfanget av repositoriet identisk med omfanget av de nedstrøms arbeidsområdene og appene du bruker til å levere innhold til forbrukerne.
• Tilgang: Du bør konfigurere tilgang til repositoriet ved hjelp av en lignende tillatelsesmodell som du har konfigurert for distribusjonssamlebåndtillatelser og arbeidsområderoller. Innholdsopprettere trenger tilgang til repositoriet.
• Dokumentasjon: Legg til tekstfiler i repositoriet for å dokumentere formålet, eierskapet, tilgangen og definerte prosesser. Dokumentasjonen kan for eksempel beskrive hvordan endringer skal iscenesettes og utføres.
• Verktøy: Hvis du vil utføre og sende endringer til et eksternt repositorium, trenger innholdsopprettere en Git-klient som Visual Studio eller Visual Studio Code. Git er et distribuert versjonskontrollsystem som sporer endringer i filene dine. Hvis du vil lære grunnleggende om Git, kan du se Hva er Git?.

Merk

Vurder å bruke Git Large File Storage (LFS) hvis du har tenkt å bruke Power BI Desktop-filer (PBIX). Git LFS tilbyr avanserte alternativer for administrasjon av filer der endringer ikke er synlige (filer som ikke kan sammenlignes), for eksempel en PBIX-fil. Du kan for eksempel bruke fillåsing for å hindre samtidige endringer i en Power BI-rapport under utvikling. Git LFS har imidlertid sin egen klient og konfigurasjon.

Samarbeid med Azure DevOps

Etter hvert som en løsning øker i omfang og kompleksitet, kan det bli nødvendig for flere innholdsopprettere og eiere å arbeide i samarbeid. Innholdsopprettere og eiere kommuniserer og samarbeider i en sentral, organisert hub ved hjelp av Azure DevOps.

Hvis du vil samarbeide og kommunisere i Azure DevOps, bruker du støttetjenester.

• Azure Boards: Innholdseiere bruker tavler til å spore arbeidselementer. Arbeidselementer tilordnes til én enkelt utvikler i teamet, og de beskriver problemer, feil eller funksjoner i løsningen og tilsvarende interessenter.
• Azure Wiki: Innholdsopprettere deler informasjon med teamet sitt for å forstå og bidra til løsningen.
• Azure Repos: Innholdsopprettere sporer endringer i det eksterne repositoriet og slår dem sammen til én enkelt løsning.
• Azure Pipelines: Pipeline-eiere konfigurerer programmatisk logikk for å distribuere løsningen, enten automatisk eller ved behov.

Samarbeidsflytdiagram

Diagrammet nedenfor viser en oversikt på høyt nivå over ett eksempel på hvordan Azure DevOps muliggjør samarbeid i bruksscenarioet for bedriftsinnholdspublisering. Fokuset for dette diagrammet er å bruke Azure DevOps til å opprette en strukturert og dokumentert innholdspubliseringsprosess.

Diagrammet viser følgende brukerhandlinger, prosesser og funksjoner.

Vare	Beskrivelse
	En innholdsoppretter lager en ny, kortvarig gren ved å klone hovedgrenen, som inneholder den nyeste versjonen av innholdet. Den nye grenen kalles ofte funksjonsgrenen, da den brukes til å utvikle en bestemt funksjon eller løse et bestemt problem.
	Innholdsoppretteren utfører sine endringer i et lokalt repositorium under utvikling.
	Innholdsoppretteren kobler endringene til arbeidselementer som administreres i Azure Boards. Works-elementer beskriver spesifikke utviklinger, forbedringer eller feilrettinger som er begrenset til grenen.
	Innholdsoppretteren utfører regelmessig endringene sine. Når du er klar, publiserer innholdsoppretteren grenen sin til det eksterne repositoriet.
	Hvis du vil teste endringene, distribuerer innholdsoppretteren løsningen til et isolert arbeidsområde for utvikling (ikke vist i dette diagrammet). Innholdsoppretteren kan også synkronisere funksjonsgrenen til arbeidsområdet ved hjelp av Fabric Git-integrering.
	Innholdsopprettere og innholdseiere dokumenterer løsningen og prosessene i en Azure Wiki, som er tilgjengelig for hele utviklingsteamet.
	Når du er klar, åpner innholdsoppretteren en pull-forespørsel om å slå sammen funksjonsgrenen til hovedgrenen.
	En teknisk eier er ansvarlig for å gjennomgå pull-forespørselen og slå sammen endringer. Når de godkjenner pull-forespørselen, slår de sammen funksjonsgrenen til hovedgrenen.
	En vellykket fletting utløser distribusjon av løsningen til et utviklingsarbeidsområde ved hjelp av en Azure Pipeline (ikke vist i dette diagrammet). Når du bruker Fabric Git-integrering, synkroniseres hovedgrenen til utviklingsarbeidsområdet.
	Utgivelsesbehandling utfører en endelig gjennomgang og godkjenning av løsningen. Denne godkjenningen hindrer at løsningen publiseres før den er klar. I virksomhetsinnholdspublisering planlegger og koordinerer en utgivelsesbehandling vanligvis innholdsutgivelsen for å teste og produksjonsarbeidsområder. De koordinerer og kommuniserer med innholdsopprettere, interessenter og brukere.
	Når utgivelsesbehandling godkjenner utgivelsen, klargjør Azure Pipelines automatisk løsningen for distribusjon. Alternativt kan en Azure Pipeline også utløse et utrullingssamlebånd for å fremme innhold mellom arbeidsområder.
	Brukere tester og validerer innhold i testarbeidsområdet. Når du bruker Git-integrasjon med Azure Pipelines for distribusjon, synkroniseres ikke testarbeidsområdet med noen gren.
	Når brukere godtar og validerer endringer, utfører utgivelsesbehandlingen en endelig gjennomgang og godkjenning av løsningen for å distribuere til produksjonsarbeidsområdet.
	Brukere viser innhold som er publisert til produksjonsarbeidsområdet. Når du bruker Git-integrasjon med Azure Pipelines for distribusjon, synkroniseres ikke produksjonsarbeidsområdet med noen gren.

For å utdype oppnår innholdsopprettere samarbeid ved hjelp av en forgreningsstrategi. En forgreningsstrategi er hvordan innholdsopprettere oppretter, bruker og slår sammen grener for effektivt å gjøre og behandle innholdsendringer. Individuelle innholdsopprettere arbeider isolert i sitt lokale repositorium. Når de er klare, kombinerer de endringene som én enkelt løsning i det eksterne repositoriet. Innholdsopprettere bør begrense arbeidet sitt til grener ved å koble dem til arbeidselementer for spesifikke utviklinger, forbedringer eller feilrettinger. Hver innholdsoppretter oppretter sin egen gren av det eksterne repositoriet for arbeidsomfanget. Arbeidet som gjøres på den lokale løsningen, utføres og sendes til en versjon av grenen i det eksterne repositoriet med en utføringsmelding. En utføringsmelding beskriver endringene som er gjort i denne utførelsen.

Hvis du vil slå sammen endringene, åpner en innholdsoppretter en pull-forespørsel. En pull-forespørsel er en innsending for fagfellevurdering som kan føre til fletting av arbeidet som gjøres i én enkelt løsning. Sammenslåing kan føre til konflikter, som må løses før grenen kan slås sammen. Gjennomgang av pull-forespørsler er viktig for å sikre at opprettere overholder organisasjonens standarder og praksiser for utvikling, kvalitet og samsvar.

Samarbeidsanbefalinger

Vi anbefaler at du definerer en strukturert prosess for hvordan innholdsopprettere skal samarbeide. Kontroller at du bestemmer:

• Hvordan arbeid er omfangsområder og hvordan grener opprettes, navngis og brukes.
• Hvordan forfattere grupperer endringer og beskriver dem med utfør meldinger.
• Hvem er ansvarlig for å gjennomgå og godkjenne pull-forespørsler.
• Hvordan sammenslåingskonflikter løses.
• Hvordan endringer i ulike grener slås sammen til én enkelt gren.
• Hvordan innhold testes og hvem som utfører testing før innhold distribueres.
• Hvordan og når endringer distribueres til utviklings-, test- og produksjonsarbeidsområder.
• Hvordan og når distribuerte endringer eller versjoner av løsningen skal rulles tilbake.

Viktig

Verdien som leveres av DevOps, er direkte proporsjonal med overholdelsen av prosessene som definerer bruken.

Et vellykket samarbeid avhenger av en veldefinert prosess. Det er viktig å tydelig beskrive og dokumentere arbeidsflyten for utvikling fra ende til ende. Sørg for at de valgte strategiene og prosessene samsvarer med eksisterende fremgangsmåter i teamet, og hvis ikke, hvordan du skal håndtere endringer. Sørg videre for at prosessene er tydelige og formidlet til alle teammedlemmer og interessenter. Sørg for at gruppemedlemmer og interessenter som er nye i prosessene, er opplært i hvordan de skal tas i bruk, og at de setter pris på verdien av vellykket Innføring av DevOps.

Power BI REST API-er

Du utvikler programmatisk logikk for å importere og distribuere innhold fra Azure DevOps ved hjelp av REST-API-ene for Power BI. Du importerer Power BI-filer (PBIX) til et arbeidsområde ved hjelp av en importoperasjon. Du bruker en datasamlebåndoperasjon til å distribuere innhold eller alt innhold til å teste eller produksjonsarbeidsområder ved hjelp av datasamlebånd for Power BI-distribusjon. Programmatisk logikk er definert i Azure Pipelines.

Vi anbefaler at du bruker en tjenestekontohaver til å ringe rest-API-er for Power BI i datasamlebåndet. En tjenestekontohaver er ment for uovervåkede, automatiserte aktiviteter, og den er ikke avhengig av brukerlegitimasjon. Noen elementer og aktiviteter støttes imidlertid ikke av REST-API-ene for Power BI eller når du bruker en tjenestekontohaver, for eksempel dataflyter.

Når du bruker en tjenestekontohaver, må du passe på å behandle tillatelser nøye. Målet ditt bør være å følge prinsippet om minst mulig rettighet. Du bør angi tilstrekkelige tillatelser for tjenestekontohaveren uten overklaringstillatelser. Bruk Azure Key Vault eller en annen tjeneste som sikkert lagrer tjenestekontohaverhemmeligheter og legitimasjon.

Forsiktig!

Hvis du har en datamodell som er lagret som et metadataformat som kan leses av mennesker, kan den ikke publiseres ved hjelp av REST-API-ene for Power BI. I stedet må du publisere det ved hjelp av XMLA-endepunktet. Du kan publisere metadatafiler ved hjelp av tredjepartsverktøy, for eksempel kommandolinjegrensesnittet i tabellredigering (CLI). Du kan også publisere metadatafiler programmatisk ved hjelp av din egen egendefinerte .NET-utvikling. Utvikling av en egendefinert løsning krever mer innsats, siden du må bruke Microsoft Tabular Object Model (TOM)-utvidelsen av klientbibliotekene for Analysis Management Object (AMO).

Azure-forløp

Azure Pipelines automatiserer programmatisk testing, administrasjon og distribusjon av innhold. Når et datasamlebånd kjøres, utføres trinn i datasamlebåndet automatisk. Pipeline-eiere kan tilpasse utløsere, trinn og funksjonalitet for å dekke distribusjonsbehov. Som sådan varierer antall og typer datasamlebånd avhengig av løsningskravene. En Azure Pipeline kan for eksempel kjøre automatiserte tester eller endre datamodellparametere før en distribusjon.

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

• Valideringssamlebånd.
• Bygg datasamlebånd.
• Frigi datasamlebånd.

Merk

Det er ikke nødvendig å ha alle tre av disse datasamlebåndene 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 over de innebygde utrullingssamlebåndene for Power BI. Du trenger for eksempel ikke å ha et valideringssamlebånd. Du kan bare bruke bygg- og utgivelsessamlebånd.

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 Best Practice Analyzer (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

Bygg datasamlebånd for å klargjøre datamodeller for publisering til Power Bi-tjeneste. Disse datasamlebåndene kombinerer serialiserte modellmetadata til én enkelt fil som senere publiseres av et utgivelsessamlebånd (beskrevet i diagrammet for utgivelsessamlebånd). Et byggforløp kan også gjøre andre endringer i metadataene, for eksempel endre parameterverdier. Byggesamlebånd produserer distribusjonsartefakter som består av metadata for datamodell (for datamodeller) og Power BI Desktop-filer (PBIX) som er klare for publisering til Power Bi-tjeneste.

Frigi datasamlebånd

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

• Pipeline for utviklingsutgivelse: 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 ved behov eller når de godkjennes. Test- og produksjonsutgivelsessamlebånd distribuerer innhold til henholdsvis et test- eller produksjonsarbeidsområde etter lanseringsgodkjenning. Utgivelsesgodkjenninger sikrer at innhold 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.

Det finnes to ulike fremgangsmåter for å publisere innhold med test- og utgivelsessamlebånd. Enten hever de innhold ved hjelp av et datasamlebånd for Power BI-distribusjon, eller de publiserer innhold til Power Bi-tjeneste fra Azure DevOps.

Diagrammet nedenfor viser den første fremgangsmåten. I denne fremgangsmåten orkestrerer utgivelsessamlebånd innholdsdistribusjon for å teste og produksjonsarbeidsområder ved hjelp av datasamlebånd for Power BI-distribusjon. Innhold fremmes gjennom utviklings-, test- og produksjonsarbeidsområder i Power BI. Selv om denne tilnærmingen er mer robust og enklere å vedlikeholde, krever den Premium-lisensiering.

Diagrammet viser følgende brukerhandlinger, prosesser og funksjoner i den første fremgangsmåten.

Vare	Beskrivelse
	I den første fremgangsmåten publiserer utgivelsessamlebånd innhold ved hjelp av XMLA-endepunktet og REST-API-ene for Power BI med utrullingssamlebånd for Power BI. Innhold publiseres og forfremmes deretter gjennom utviklings-, test- og produksjonsarbeidsområder. Power BI-utrullingssamlebånd og XMLA-lese-/skriveendepunktet er Premium-funksjoner.
	Enten en vellykket grenfletting eller fullføring av et oppstrøms datasamlebånd utløser build-datasamlebåndet. Byggeforløpet klargjør deretter innhold for publisering, og utløser datasamlebåndet for utvikling.
	Datasamlebåndet for utvikling publiserer innhold til utviklingsarbeidsområdet ved hjelp av XMLA-endepunktet (for metadata for datamodell) eller REST-API-er for Power BI (for Power BI Desktop-filer, som kan inneholde datamodeller og rapporter). Utviklingssamlebåndet bruker kommandolinjegrensesnittet (CLI) for tabellredigering til å distribuere metadata for datamodell ved hjelp av XMLA-endepunktet.
	En utgivelsesgodkjenning eller behovsbetinget utløser aktiverer testutgivelsessamlebåndet.
	Testversjonssamlebåndet distribuerer innhold ved hjelp av POWER BI REST API-distribusjonsoperasjoner, som kjører utrullingsforløpet for Power BI.
	Utrullingssamlebåndet for Power BI fremmer innhold fra utviklingsarbeidsområdet til testarbeidsområdet. Etter distribusjon utfører utgivelsessamlebåndet aktiviteter etter distribusjon ved hjelp av REST-API-ene for Power BI (vises ikke i diagrammet).
	En utgivelsesgodkjenning eller behovsbetinget utløser aktiverer datasamlebåndet for produksjonsutgivelser.
	Datasamlebåndet for produksjonsutgivelser distribuerer innhold ved hjelp av POWER BI REST API-distribusjonsoperasjoner, som kjører utrullingssamlebåndet for Power BI.
	Utrullingssamlebåndet for Power BI fremmer innhold fra testarbeidsområdet til produksjonsarbeidsområdet. Etter distribusjon utfører utgivelsessamlebåndet aktiviteter etter distribusjon ved hjelp av REST-API-ene for Power BI (vises ikke i diagrammet).

Diagrammet nedenfor viser den andre fremgangsmåten. Denne fremgangsmåten bruker ikke utrullingssamlebånd. I stedet bruker den utgivelsessamlebånd til å publisere innhold for å teste og produksjonsarbeidsområder fra Azure DevOps. Denne andre fremgangsmåten krever ikke Premium-lisensiering når du publiserer bare Power BI Desktop-filer med REST-API-ene for Power BI. Det innebærer mer oppsettsinnsats og kompleksitet, fordi du må administrere distribusjon utenfor Power BI. Utviklingsteam som allerede bruker DevOps for dataløsninger utenfor Power BI, kan være mer kjent med denne tilnærmingen. Utviklingsteam som bruker denne tilnærmingen, kan konsolidere distribusjon av dataløsninger i Azure DevOps.

Diagrammet viser følgende brukerhandlinger, prosesser og funksjoner i den andre fremgangsmåten.

Vare	Beskrivelse
	I den andre fremgangsmåten publiserer utgivelsessamlebånd innhold ved hjelp av XMLA-endepunktet og Bare REST-API-ene for Power BI. Innhold publiseres til utviklings-, test- og produksjonsarbeidsområder.
	Enten en vellykket grenfletting eller fullføring av et oppstrøms datasamlebånd utløser build-datasamlebåndet. Byggeforløpet klargjør deretter innhold for publisering, og utløser datasamlebåndet for utvikling.
	Datasamlebåndet for utvikling publiserer innhold til utviklingsarbeidsområdet ved hjelp av XMLA-endepunktet (for metadata for datamodell) eller REST-API-er for Power BI (for Power BI Desktop-filer, som kan inneholde datamodeller og rapporter). Utviklingssamlebåndet bruker kommandolinjegrensesnittet (CLI) for tabellredigering til å distribuere metadata for datamodell ved hjelp av XMLA-endepunktet.
	En utgivelsesgodkjenning eller behovsbetinget utløser aktiverer testutgivelsessamlebåndet.
	Datasamlebåndet for utviklingsutgivelse publiserer innhold til testarbeidsområdet ved hjelp av XMLA-endepunktet (for metadata for datamodell) eller REST-API-er for Power BI (for Power BI Desktop-filer, som kan inneholde datamodeller og rapporter). Utviklingssamlebåndet bruker kommandolinjegrensesnittet (CLI) for tabellredigering til å distribuere metadata for datamodell ved hjelp av XMLA-endepunktet. Etter distribusjon utfører utgivelsessamlebåndet aktiviteter etter distribusjon ved hjelp av REST-API-ene for Power BI (vises ikke i diagrammet).
	En utgivelsesgodkjenning eller behovsbetinget utløser aktiverer datasamlebåndet for produksjonsutgivelser.
	Datasamlebåndet for utviklingsutgivelse publiserer innhold til produksjonsarbeidsområdet ved hjelp av XMLA-endepunktet (for metadata for datamodell) eller REST-API-er for Power BI (for Power BI Desktop-filer, som kan inneholde datamodeller og rapporter). Utviklingssamlebåndet bruker kommandolinjegrensesnittet (CLI) for tabellredigering til å distribuere metadata for datamodell ved hjelp av XMLA-endepunktet. Etter distribusjon utfører utgivelsessamlebåndet aktiviteter etter distribusjon ved hjelp av REST-API-ene for Power BI (vises ikke i diagrammet).

Utgivelsessamlebånd bør administrere aktiviteter etter distribusjon. Disse aktivitetene kan omfatte å angi semantisk modelllegitimasjon eller oppdatere Power BI-appen for test- og produksjonsarbeidsområder. Vi anbefaler at du konfigurerer varsler for å informere relevante personer om distribusjonsaktiviteter .

Tips

Ved hjelp av et repositorium for versjonskontroll kan innholdsopprettere opprette en tilbakerullingsprosess. Tilbakerullingsprosessen kan reversere den siste distribusjonen ved å gjenopprette den forrige versjonen. Vurder å opprette et eget sett med Azure Pipelines som du kan utløse for å rulle tilbake produksjonsendringer. Tenk nøye gjennom hvilke prosesser og godkjenninger som kreves for å starte en tilbakerulling. Kontroller at disse prosessene er dokumentert.

Datasamlebånd for Power BI-distribusjon

Et datasamlebånd for Power BI-distribusjon består av tre faser: utvikling, test og produksjon. Du tilordner ett enkelt Power BI-arbeidsområde til hvert trinn i utrullingssamlebåndet. Når en distribusjon oppstår, fremmer utrullingssamlebåndet Power BI-elementer fra ett arbeidsområde til et annet.

Et utgivelsessamlebånd for Azure Pipelines bruker REST-API-ene for Power BI til å distribuere innhold ved hjelp av et utrullingssamlebånd for Power BI. Tilgang til både arbeidsområdet og utrullingssamlebåndet kreves for brukerne som utfører en distribusjon. Vi anbefaler at du planlegger datasamlebåndtilgang for distribusjon, slik at datasamlebåndbrukere kan vise distribusjonslogg og sammenligne innhold.

Tips

Når du skiller dataarbeidsområder fra rapporteringsarbeidsområder, bør du vurdere å bruke Azure Pipelines til å organisere innholdspublisering med flere datasamlebånd for Distribusjon av Power BI. Semantisk modell distribueres først, og deretter oppdateres de. Til slutt distribueres rapporter. Denne fremgangsmåten hjelper deg med å forenkle distribusjonen.

Premium-lisensiering

Power BI-utrullingssamlebånd og XMLA-lese-/skriveendepunktet er Premium-funksjoner. Disse funksjonene er tilgjengelige med Power BI Premium-kapasitet og Power BI Premium per bruker (PPU).

PPU er en kostnadseffektiv måte å administrere bedriftsinnholdspublisering for utviklings- og testarbeidsområder på, som vanligvis har få brukere. Denne tilnærmingen har den ekstra fordelen av å isolere utviklings- og testarbeidsbelastninger fra produksjonsarbeidsbelastninger.

Merk

Du kan fortsatt konfigurere publisering av bedriftsinnhold uten en Premium-lisens, som beskrevet av den andre fremgangsmåten i delen for utgivelsesforløp . I den andre fremgangsmåten bruker du Azure Pipelines til å administrere distribusjon av Power BI Desktop-filer til utviklings-, test- og produksjonsarbeidsområder. Du kan imidlertid ikke distribuere modellmetadata ved hjelp av XMLA-endepunktet fordi det ikke er mulig å publisere en semantisk metadataformatmodell med REST-API-ene for Power BI. Det er heller ikke mulig å promotere innhold gjennom miljøer med utrullingssamlebånd uten en Premium-lisens.

Konfigurasjon av gateway

Vanligvis kreves det en datagateway når du får tilgang til datakilder som befinner seg i det private organisasjonsnettverket eller et virtuelt nettverk. De to formålene med en gateway er å oppdatere importerte data, og vise en rapport som spør etter en live-tilkobling eller DirectQuery-semantisk modell (ikke avbildet i scenariodiagrammet).

Når du arbeider med flere miljøer, er det vanlig å konfigurere utviklings-, test- og produksjonstilkoblinger til ulike kildesystemer. I dette tilfellet kan du bruke datakilderegler og parameterregler til å behandle verdier som er forskjellige mellom miljøer. Du kan bruke Azure Pipelines til å administrere gatewayer ved hjelp av gateway-operasjonene til REST-API-ene for Power BI.

Merk

En sentralisert datagateway i standardmodus anbefales på det sterkeste over gatewayer i personlig modus. I standardmodus støtter datagatewayen live-tilkobling og DirectQuery-operasjoner (i tillegg til planlagte dataoppdateringsoperasjoner).

Systemtilsyn

Aktivitetsloggen registrerer hendelser som forekommer i Power Bi-tjeneste. Power BI-administratorer kan bruke aktivitetsloggen til å overvåke distribusjonsaktiviteter.

Du kan bruke API-ene for skanning av Power BI-metadata til å opprette en leierbeholdning. API-resultatene er nyttige for å bekrefte hvilke elementer som er distribuert til hvert arbeidsområde, for å kontrollere avstamming og for å validere sikkerhetsinnstillinger.

Det finnes også en overvåkingslogg i Azure DevOps, som er utenfor Power Bi-tjeneste. Azure DevOps-administratorer kan bruke overvåkingsloggen til å se gjennom aktiviteter i eksterne repositorier og datasamlebånd.

Relatert innhold

Hvis du vil ha andre nyttige scenarier for å hjelpe deg med implementeringsbeslutninger i Power BI, kan du se artikkelen om bruksscenarioer i Power BI.