Planlegging av Power BI-implementering: Utvikle innhold og behandle endringer

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 å utvikle innhold og behandle endringer som en del av administrasjonen av innholdslivssyklusen. Det er primært rettet mot:

• 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 roller som utgivelsesledere, som håndterer livssyklusen til innholdsutgivelser, eller 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 er prosessene og praksisene du bruker til å håndtere innhold fra opprettingen til eventuell pensjonering. I den første fasen avfor livssyklusadministrasjon planlegger og utformer du innhold, som innebærer løsningsplanlegging og viktige beslutninger som påvirker din tilnærming til livssyklusadministrasjon. I den andre fasen utvikler du innhold og behandler endringer.

Administrasjon av innholdsendringer i løpet av livssyklusen er viktig for å sikre effektivt samarbeid mellom innholdsopprettere og stabil og konsekvent levering av innhold til forbrukerne.

Bildet nedenfor viser livssyklusen til Power BI-innhold, utheving av trinn to, der du utvikler innhold og administrerer endringer.

Notat

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

Tips

Denne artikkelen fokuserer på viktige beslutninger og vurderinger for å hjelpe deg med å utvikle innhold og administrere endringer gjennom hele livssyklusen. Hvis du vil ha mer veiledning om hvordan du utvikler innhold og administrerer endringer, kan du se:

• Hva er livssyklusadministrasjon i Microsoft Fabric?: Denne artikkelen inneholder en teknisk innføring og opplæring til Fabric Git-integrerings- og distribusjonssamlebånd.
• Anbefalte fremgangsmåter for livssyklusadministrasjon: Denne artikkelen inneholder praktiske tips og veiledning for bruk av funksjonene for livssyklusadministrasjon i Fabric og Power BI for å utvikle innhold og administrere endringer.
• Power BI Desktop OneDrive- og SharePoint-integrering: Denne artikkelen inneholder en oversikt over alternativene for å bruke og lagre filer som er lagret i OneDrive for arbeid og skole eller SharePoint når du utfører versjonskontroll med PBIX-filer.
• Kom i gang med Git i Azure Repos: Denne serien med artikler inneholder praktiske tips, opplæringer og veiledning for å utføre kildekontroll ved hjelp av et Git-repositorium i Azure Repos.

Innholdsopprettere og eiere bør behandle innholdsendringer ved hjelp av versjonskontroll. Versjonskontroll er praksisen med å administrere endringer i filer eller kode i et sentralt repositorium. Denne praksisen forenkler mer effektiv samarbeid og innholdsbehandling.

Andre fordeler med versjonskontroll inkluderer muligheten til å:

• Slå sammen endringer fra flere innholdsopprettere, og håndter sammenslåingskonflikter.
• Identifiser hvilket innhold som er endret, og hva som er endret i innholdet.
• Koble innholdsendringer til bestemte arbeidselementer.
• Grupper endringer i distinkte versjoner med versjonslogg.
• Rull tilbake endringer eller hele versjoner av innhold.

Tips

Vi anbefaler at du bruker versjonskontroll for alt innhold du oppretter, der det er mulig. Bruk av versjonskontroll har betydelige fordeler både for innholdsopprettere og forbrukere, og reduserer risikoen for forstyrrelser på grunn av filtap eller manglende evne til å rulle tilbake endringer.

Det første trinnet for å konfigurere versjonskontroll er å bestemme hvordan du skal utvikle innhold.

Bestem hvordan du utvikler innhold

Avhengig av hvordan du redigerer innhold, tar du forskjellige avgjørelser om hvordan du administrerer det. For Power BI-rapporter og semantiske modeller har for eksempel en Power BI Desktop-fil (PBIX) færre alternativer for versjonskontroll sammenlignet med Power BI Desktop-prosjekt (PBIP) format. Det er fordi en PBIX-fil er et binært format, mens PBIP-formatet inneholder tekstbasert innhold og metadata som kan leses av mennesker. Hvis du har innhold som kan leses av mennesker og metadata, kan du gjøre det enklere å spore modell- og rapportendringer ved hjelp av kildekontroll. Kildekontroll er når du viser og behandler endringer i innhold til koden og metadataene.

Tips

Når du utvikler semantiske modeller og rapporter ved hjelp av Power BI Desktop, anbefaler vi at du bruker PBIP-filer i stedet for PBIX-filer. Når du utvikler semantiske modeller ved hjelp av XMLA-verktøy, anbefaler vi at du bruker TMDL-formatet (Tabular Model Definition Language) i stedet for BIM-filer.

PBIP- og TMDL-formatene støtter enklere sporing og sammenslåing av endringer på objektnivå. Dette betyr at du kan vise og behandle endringer i individuelle objekter, for eksempel DAX-mål eller tabeller.

Power BI Desktop

Du kan bruke Power BI Desktop til å opprette semantiske modeller eller rapporter, som du kan lagre som PBIX- eller PBIP-filer. Det finnes flere egendefinerte innholdsfiler som du også kan bruke når du bruker Power BI Desktop.Når du bruker Power BI Desktop til å opprette innhold, bør du ta noen viktige avgjørelser:

• Hvilket filformat som skal brukes: Du kan lagre innhold som PBIX- eller PBIP-filer. Git-integrering krever for eksempel at du bruker PBIP-filer, selvbetjente opprettere kan finne PBIX-filer enklere å administrere og vedlikeholde i Teams, SharePoint eller OneDrive.
• Slik administrerer du egendefinert innhold: Du kan legge til temaer, egendefinerte visualobjekter eller bilder i Power BI Desktop-filer, noe som kan kreve tydelige hensyn for livssyklusbehandling. Når innholdsopprettere for eksempel lager sine egne egendefinerte visualobjekter, bør de lagre og administrere den visuelle definisjonen i en egen fil.
• Slik administrerer du forhåndsvisningsfunksjoner: Du kan velge å forhåndsvise funksjoner eller innstillinger i Power BI Desktop, som endrer innhold og hvordan du bruker det. Du kan for eksempel utføre flere trinn for å validere innhold som bruker forhåndsvisningsfunksjoner.

Webredigering

Bestemt innhold, for eksempel dataflyter, instrumentbord og målstyringer, kan bare opprettes i Stoff-portalen. Du kan også opprette eller endre noe innhold, for eksempel semantiske modeller, rapporter og paginerte rapporter, både i Stoff-portalen eller ved hjelp av lokale verktøy. Når du oppretter innhold ved hjelp av nettredigering, bør du ta viktige avgjørelser:

• Slik behandler du endringer: Du kan gjøre endringer i mange elementtyper ved hjelp av nettredigering, men disse endringene kan lagres umiddelbart, og overskrive tidligere versjoner. Hvis du for eksempel samarbeider med andre, bør du unngå nettredigering på delte elementer, i stedet for å arbeide på din egen kopi.
• Slik henter du sikkerhetskopier av innhold: Du kan opprette innhold som rapporter eller semantiske modeller ved hjelp av webredigering, men disse elementene ikke kan lastes ned til lokale PBIX-filer. Du kan for eksempel velge å sikkerhetskopiere dette innholdet ved å hente og lagre metadataene.

Tips

Når du utvikler dataflyter og målstyringer, anbefaler vi at du henter elementdefinisjonene for å behandle endringer og lagre en sikkerhetskopi. Du kan automatisere henting av dataflyt og målstyring ved hjelp av rest-API-ene for Fabric. Spesielt kan du bruke henholdsvis Hent dataflyt og Få målstyringer endepunkter.

Forsiktighet

Noe innhold, for eksempel instrumentbord, har ikke mulighet til å hente en definisjon. For dette innholdet kan du ikke enkelt spore endringer eller hente en sikkerhetskopi.

Andre verktøy

Du kan bruke andre verktøy til å opprette eller administrere bestemte typer innhold. Disse verktøyene kan gi ekstra fordeler, passe bedre til arbeidsflyten eller være nødvendig for å administrere bestemte funksjoner eller innholdstyper. Du kan bruke både andre Microsoft-verktøy eller tredjepartsverktøy til å opprette og behandle innhold. Andre verktøy du kan bruke til å opprette eller behandle innhold, er som følger.

• Visual Studio eller Visual Studio Code: Et integrert utviklingsmiljø der utviklere kan opprette og administrere semantiske modeller eller Fabric-notatblokker. Med både Visual Studio- og Visual Studio Codekan utviklere også utføre kildekontrolladministrasjon (SCM) ved å forplikte og skyve lokale endringer til et eksternt repositorium.
• Tabellredigering: Et tredjepartsverktøy for utvikling og administrering av semantiske modeller.
• Excel: Et klientverktøy for pivottabeller og dynamiske tilkoblede tabeller som fungerer med en semantisk modell.
• Power BI Report Builder: Et skrivebordsprogram for å opprette paginerte rapportfiler (RDL).

Når du oppretter innhold ved hjelp av andre verktøy, bør du ta viktige avgjørelser:

• Slik administrerer du lisenser: Andre verktøy kan kreve flere lisenser som du bør administrere.
• Slik publiserer du innhold: Andre verktøy kan kreve flere trinn for å publisere innhold, for eksempel ved hjelp av XMLA-endepunkter eller REST-API-er for Power BI.

Når du har bestemt deg for hvordan du skal opprette innhold, må du velge hvor du skal publisere og teste innhold mens du utvikler det.

Bestem hvordan du skal konfigurere og bruke arbeidsområder

Når du utvikler innhold, bør du bruke flere arbeidsområder (eller faser) til å skille produksjonsinnhold som brukes av organisasjonen, fra innhold som utvikles eller valideres. Det er flere fordeler med å bruke separate arbeidsområder for innholdet:

• Du kan utvikle og teste innhold uten å påvirke innholdet som er i bruk. Dette unngår endringer som kan føre til utilsiktet forstyrrelse av innholdet i produksjonen.
• Du kan bruke separate ressurser for utvikling og testing av innhold, for eksempel ved hjelp av separate datagatewayer eller Stoffkapasiteter. Dette unngår at ressurser som brukes til utvikling og testing forstyrrer produksjonsarbeidsbelastninger, noe som forårsaker trege dataoppdateringer eller rapporter.
• Du kan opprette en mer strukturert prosess for å utvikle, teste og frigi innhold ved å ha diskrete miljøer for hvert av disse stadiene. Dette hjelper deg med å forbedre produktiviteten.

I Fabric og Power BI anbefaler vi at du bruker separate Fabric-arbeidsområder, som beskrevet i på leiernivå og planleggingsartikler på arbeidsområdenivå.

Viktig

Bruk av separate miljøer er et viktig trinn for å sikre at innholdslivssyklusbehandlingen lykkes.

Det finnes flere måter å bruke Fabric-arbeidsområder på for å skille miljøer. I tillegg til det lokale miljøet bruker du vanligvis to eller flere arbeidsområder til å administrere innhold i løpet av livssyklusen.

Svar på følgende spørsmål når du planlegger hvordan du skal bruke separate arbeidsområder gjennom hele livssyklusen til dette innholdet:

• Hvor mange arbeidsområder trenger du?
• Vil du separate arbeidsområder etter elementtype?
• Hvem har tilgang til hvert arbeidsområde?
• Vil arbeidsområdene tilhøre en fabric-utrullingssamlebånd, eller vil du organisere distribusjon ved hjelp av andre tilnærminger, for eksempel ved å bruke Azure Pipelines?
• Hvordan administrerer du publisering på tvers av arbeidsområder? Må du for eksempel sikre at rapporter i et testarbeidsområde for rapporter kobler til semantiske modeller i et eget testarbeidsområde for dataelementer?
• Må du også bruke separate støtteressurser for elementer i produksjonsarbeidsområder, for eksempel en separat lokal datagatewayklynge?

De følgende avsnittene gir en oversikt på høyt nivå over de ulike tilnærmingene du kan ta til separate arbeidsområder for å legge til rette for livssyklusadministrasjon.

Notat

Avsnittene nedenfor fokuserer på hvordan du kan konfigurere og bruke separate arbeidsområder. Du kan distribuere innhold til disse arbeidsområdene ved hjelp av én av følgende fire fremgangsmåter:

• Publisering fra Power BI Desktop.
• Distribuer innhold fra et annet arbeidsområde ved hjelp av fabric-utrullingssamlebånd.
• Synkroniserer innhold fra et eksternt Git-repositorium ved hjelp av Git-integrering.
• Distribuerer innhold programmatisk ved hjelp av REST-API-er for Fabric, Rest-API-er for Power BI eller XMLA-endepunkter.

Hvis du vil ha mer informasjon om disse fremgangsmåtene for å distribuere innhold, kan du se trinn 4: Distribuere innhold senere i denne serien.

Test- og produksjonsarbeidsområder

Når du leverer enklere innhold som ikke er kritisk for organisasjonen, kan to arbeidsområder ofte være tilstrekkelige. I dette scenarioet har innholdsopprettere vanligvis begrenset samarbeid på de samme elementene, og utvikler innhold lokalt.

Diagrammet nedenfor viser et eksempel på høyt nivå på hvordan du kan bruke separate miljøer med bare et test- og produksjonsarbeidsområde.

Diagrammet viser følgende prosesser og komponenter for å skille arbeidsområder i denne fremgangsmåten.

element	beskrivelse
	Innholdsopprettere utvikler innhold i sitt lokale miljø.
	Når du er klar, publiserer innholdsopprettere innhold til et testarbeidsområde. Innholdsopprettere kan utvikle innhold som bare kan produseres med nettredigering og utføre innholdsvalidering i testarbeidsområdet.
	Når du er klar, distribuerer innholdsopprettere innhold til et produksjonsarbeidsområde. Innholdsopprettere distribuerer innhold ved å publisere en Power BI-app eller dele innhold fra arbeidsområdet i produksjonsarbeidsområdet.

Notat

Det finnes mange forskjellige måter å konfigurere og bruke separate arbeidsområder på, og distribuere innhold mellom disse arbeidsområdene. Vi anbefaler imidlertid at du ikke utfører lokal utvikling, og deretter publiserer innhold direkte til et produksjonsarbeidsområde. Dette kan føre til forstyrrelser og feil som kan forebygges.

Arbeidsområder for utvikling, test og produksjon

Når du leverer forretningskritisk innhold, bruker du vanligvis tre eller flere separate arbeidsområder. I dette scenarioet samarbeider innholdsopprettere ofte i et ekstra utviklingsarbeidsområde som inneholder den nyeste versjonen av løsningen.

Diagrammet nedenfor viser et eksempel på høyt nivå på hvordan du kan bruke separate miljøer med et arbeidsområde for utvikling, test og produksjon.

Diagrammet viser følgende prosesser og komponenter for å skille arbeidsområder i denne fremgangsmåten.

element	beskrivelse
	Innholdsopprettere utvikler innhold i sitt lokale miljø.
	Når du er klar, publiserer innholdsopprettere innhold til et arbeidsområde for utvikling. I arbeidsområdet for utvikling kan innholdsopprettere utvikle innhold som bare kan produseres med nettredigering. Innholdsopprettere kan også validere innhold i utviklingsarbeidsområdet.
	Når du er klar, distribuerer innholdsopprettere innhold til et testarbeidsområde. I testarbeidsområdet validerer brukere innhold, enten i arbeidsområdet eller i en app.
	Når du er klar, distribuerer innholdsopprettere innhold til et produksjonsarbeidsområde. Innholdsopprettere distribuerer innhold ved å publisere en Power BI-app eller dele innhold fra arbeidsområdet i produksjonsarbeidsområdet.

Notat

Du kan bruke opptil ti forskjellige miljøer med utrullingssamlebånd. Det kan for eksempel hende at du vil ha et pre-produksjonsmiljø mellom test og produksjon som er spesielt for spesielle typer validering, for eksempel ytelsestesting.

Privat arbeidsområde med Git-integrering

Når du leverer forretningskritisk innhold, kan hver utvikler også bruke sitt eget, privat arbeidsområde for utvikling. I dette scenarioet kan et privat arbeidsområde gjøre det mulig for innholdsopprettere å teste innhold i Stoff-portalen, eller bruke funksjoner som planlagt oppdatering uten å risikere forstyrrelser for andre i utviklingsteamet. Innholdsopprettere kan også utvikle innhold i Stoff-portalen her, for eksempel dataflyter. Private arbeidsområder kan være et godt valg når du administrerer innholdsendringer ved hjelp av Git-integrering sammen med Azure DevOps.

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.

Diagrammet nedenfor viser et eksempel på høyt nivå på hvordan du kan bruke separate miljøer ved hjelp av et privat arbeidsområde med Git-integrering.

Notat

Diagrammet viser separate utviklere som arbeider med separate grener av en løsning (gren én og gren to) før de slår sammen endringene til en hovedgren. Dette er en forenklet skildring av en Git-forgreningsstrategi for å illustrere hvordan utviklere kan integrere endringene sine med et eksternt Git-repositorium og dra nytte av Git-integrering i Fabric.

Diagrammet viser følgende prosesser og komponenter for å skille arbeidsområder i denne fremgangsmåten.

element	beskrivelse
	Hver innholdsoppretter utvikler innhold i sitt eget lokale miljø.
	Når de er klare, utfører og sender innholdsopprettere endringene sine til et eksternt repositorium, for eksempel et Azure Repos Git-repositorium.
	I det eksterne Git-repositoriet kan innholdsopprettere spore og behandle innholdsendringer ved hjelp av kildekontroll og forgrene og slå sammen innhold for å legge til rette for samarbeid.
	Innholdsopprettere synkroniserer en gren av det eksterne repositoriet med et privat arbeidsområde. Når du har synkronisert, er de siste endringene som en oppretter utfører og skyver til grenen, synlige i det private arbeidsområdet. Ulike innholdsopprettere arbeider på egen hånd, og skiller grener etter hvert som de gjør endringer.
	I de private arbeidsområdene kan innholdsopprettere utvikle innhold ved hjelp av nettredigering og validere sine egne endringer. Endringer i innhold som gjøres av webredigering, kan synkroniseres med grenen i Git-repositoriet når innholdsoppretteren utfører og skyver disse endringene fra arbeidsområdet. Ulike innholdsopprettere arbeider i sine egne, separate private arbeidsområder.
	Når de er klare, utfører innholdsopprettere en pull-forespørsel om å slå sammen endringene i hovedgrenen av løsningen.
	Etter sammenslåing av endringer synkroniseres hovedgrenen med utviklingsarbeidsområdet.
	I utviklingsarbeidsområdet kan innholdsopprettere utvikle innhold som ikke støttes av Fabric Git-integrering, for eksempel instrumentbord. Innholdsopprettere validerer også den integrerte løsningen som inneholder alle de nyeste endringene.
	Når du er klar, distribuerer innholdsopprettere innhold til et testarbeidsområde. I testarbeidsområdet utfører brukere brukergodkjenningstesting av innhold.
	Når du er klar, distribuerer innholdsopprettere innhold til et produksjonsarbeidsområde. Innholdsopprettere distribuerer innhold ved å publisere en Power BI-app eller dele innhold fra arbeidsområdet i produksjonsarbeidsområdet.

Støtteressurser for arbeidsområder

Når du bruker separate miljøer, bør du også vurdere hvordan dette vil påvirke ulike støtteressurser som du bruker i disse miljøene. For disse støtteressursene bør du vurdere om du også trenger å dele dem inn i samme antall faser, eller hvordan du koordinerer bruken av dem på tvers av disse miljøene.

• gatewayer: Vurder å bruke separate lokale datagatewayklynger og VNet-gatewayer for produksjonsarbeidsbelastninger. Dette er nyttig for å forhindre forstyrrelser, men også for å sikre oppetid når du trenger å oppdatere disse gatewayene.
• Apps: Vurder å ha separate apper for test- og produksjonsarbeidsområder. Det er ikke mulig å distribuere eller kopiere apper mellom faser. Apper i testarbeidsområdet er ment å hjelpe deg med å teste innhold og appopplevelsen før du distribuerer endringer i produksjonsarbeidsområdet. Apper i produksjonsarbeidsområdet er ment å levere innhold til sluttbrukere i en strukturert og opplevelse.
• Azure DevOps: Hvis du har tenkt å bruke Azure DevOps til å samarbeide og organisere kildekontroll og distribusjon, bør du vurdere hvordan du bruker grener og Azure Pipelines til å distribuere innhold mellom disse miljøene. Hvis du vil ha mer informasjon om hvordan du bruker Azure Pipelines til å distribuere innhold, kan du se trinn 4: Distribuere innhold.

Når du har bestemt deg for hvordan du skal konfigurere og bruke arbeidsområder, er neste trinn å bestemme hvordan du skal utføre versjonskontroll for å spore og behandle innholdsendringer.

Bestem hvordan du skal bruke versjonskontroll

I Power BI kan du utføre versjonskontroll enten ved hjelp av SharePoint/OneDrive, eller ved hjelp av et eksternt Git-repositorium, for eksempel Azure Repos, som er en komponent i Azure DevOps. I begge fremgangsmåtene legger du til lokale innholdsfiler på en ekstern lagringsplassering for å hjelpe til med å spore og administrere endringer. Vi anbefaler at du bare bruker SharePoint eller OneDrive for mindre og enklere prosjekter, ettersom det mangler funksjoner og robusthet for å støtte større eller mer kompliserte scenarier.

Her er noen generelle vurderinger for å hjelpe deg med å konfigurere og bruke versjonskontroll.

• Varsler: Du bør konfigurere varsler for når andre legger til, fjerner eller endrer kritiske filer.
• omfang: Definer omfanget av den eksterne lagringsplasseringen tydelig. Ideelt sett er omfanget av den eksterne lagringsplasseringen identisk med omfanget av de nedstrøms arbeidsområdene og appene du bruker til å levere innhold til forbrukerne.
• Access-: Du bør konfigurere tilgang til den eksterne lagringsplasseringen ved hjelp av en lignende tillatelsesmodell som du har konfigurert for distribusjonssamlebåndtillatelser og arbeidsområderoller. Innholdsopprettere trenger tilgang til den eksterne lagringsplasseringen.
• Dokumentasjon: Legg til tekstfiler på den eksterne lagringsplasseringen for å beskrive plasseringen for ekstern lagring og formålet, eierskapet, tilgangen og definerte prosesser.

De følgende avsnittene beskriver hver tilnærming og viktige hensyn for å bestemme hvilken du skal bruke.

Versjonskontroll ved hjelp av SharePoint eller OneDrive for arbeid og skole

SharePoint har innebygd versjonskontroll for filer. Innholdsopprettere kan utvikle semantiske modeller eller rapporter lokalt, og endringene synkroniseres til et SharePoint- eller OneDrive for Work and School-dokumentbibliotek.

Tips

Bruk SharePoint eller OneDrive bare for versjonskontroll i enklere, mindre scenarier, for eksempel selvbetjent innholdspublisering. For større eller mer kompliserte scenarioer bør du vurdere å utføre kildekontroll ved hjelp av et eksternt Git-repositorium.

Diagrammet nedenfor viser en oversikt på høyt nivå over hvordan du utfører versjonskontroll ved hjelp av SharePoint eller OneDrive.

Diagrammet beskriver følgende prosesser og komponenter.

element	beskrivelse
	Innholdsopprettere utvikler semantiske modeller og rapporter i sitt lokale miljø og lagrer disse modellene og rapportene som PBIX-filer.
	Når de er klare, lagrer innholdsopprettere endringene sine, som de synkroniserer til et eksternt SharePoint- eller OneDrive for Work and School-bibliotek.
	I det eksterne biblioteket sporer innholdsopprettere endringer på filnivå som forenkler versjonskontroll.
	Innholdsopprettere kan koble en publisert semantisk modell eller rapport til en PBIX-fil for å forenkle OneDrive-oppdatering. OneDrive-oppdatering publiserer automatisk innholdsendringer hver time.
	I Fabric-arbeidsområdet ser innholdsopprettere endringene i Power BI-innhold etter at OneDrive-oppdateringen er fullført.

Viktig

Du kan bare utføre versjonskontroll ved hjelp av SharePoint- eller OneDrive for Power BI Desktop-filer som inneholder semantiske modeller eller rapporter. Du kan ikke enkelt utføre versjonskontroll ved hjelp av SharePoint eller OneDrive for andre Power BI-elementtyper, for eksempel dataflyter, eller for stoffelementtyper som notatblokker. For disse andre elementtypene bør du utføre versjonskontroll ved hjelp av et eksternt Git-repositorium, for eksempel Azure Repos.

Hvis du vil oppsummere, kan innholdsopprettere koble en publisert semantisk modell eller rapport til en PBIX-fil som er lagret i et SharePoint- eller OneDrive for Work and School-bibliotek. Med denne fremgangsmåten trenger ikke innholdsopprettere lenger å publisere den semantiske modellen for å se endringer. I stedet er endringene synlige etter en automatisk OneDrive-oppdatering, som skjer hver time. Selv om det er praktisk, kommer denne tilnærmingen med noen hensyn, og den kan ikke enkelt reverseres.

Selv om det er enkelt å konfigurere og administrere, har versjonskontroll med SharePoint eller OneDrive flere begrensninger. Det er for eksempel ikke mulig å vise endringer i innholdet, og det er heller ikke mulig å sammenligne versjoner. I tillegg er det ikke mulig å konfigurere mer avanserte prosesser for å administrere disse endringene (for eksempel forgrenings- eller pull-forespørsler, beskrevet senere i denne artikkelen).

Vurder å bruke SharePoint eller OneDrive til å spore og behandle endringer i følgende scenarioer:

• Innhold består av bare semantiske modeller eller rapporter som er lagret som PBIX-filer.
• Selvbetjente brukere oppretter og administrerer innholdet.
• Innholdsopprettere samarbeider ved hjelp av Microsoft Teams.
• Innholdsopprettere er uerfarne med Git og administrasjon av kildekontroll.
• Innholdsopprettere administrerer ett enkelt element med begrenset kompleksitet og samarbeid.
• PBIX-filene har en følsomhetsetikett som krypterer innholdet.

Notat

OneDrive og SharePoint støtter innhold som har følsomhetsetiketter, bortsett fra noen begrensede scenarier. Fabric Git-integrering støtter derimot ikke følsomhetsetiketter.

Unngå å bruke SharePoint eller OneDrive til å spore og behandle endringer i følgende scenarioer:

• Innhold består av andre elementtyper enn semantiske modeller og rapporter.
• Innholdet er komplekst eller stort i omfang.
• Innholdsopprettere må samarbeide på samme element samtidig.

Avsnittene nedenfor beskriver flere hensyn for effektiv bruk av versjonskontroll ved hjelp av SharePoint eller OneDrive med Power BI.

Microsoft Teams-integrering

Du kan bruke dokumentbibliotekene fra Microsoft Teams hvis innholdsopprettere bruker det til samarbeidet. Dokumentbiblioteker er SharePoint-områder, og bruk av dokumentbibliotekene (i stedet for et eget SharePoint-nettsted eller onedrive-mappe) sikrer sentralisering av innhold, filer og samarbeid.

Innsjekkings- og utsjekkingsfiler

Du bør sjekke ut filer du arbeider med for å unngå mulige endringskonflikter. Når endringene er fullført, sjekker du inn filene med kommentarer som beskriver endringen. Når du sjekker inn og sjekker ut filer, kan du forbedre samarbeidet mellom innholdsopprettere når du bruker SharePoint eller OneDrive for Arbeid og Skole for versjonskontroll. Hvis du sjekker inn og sjekker ut filer med flere innholdsopprettere, kan du endre SharePoint-nettstedsbiblioteket for å vise den siste oppdateringen og kommentarene fra den siste innsjekkingen.

Versjonslogg

Sørg for at du sikkerhetskopierer innhold til en egen plassering i tilfelle uventede forstyrrelser i dokumentbiblioteket på SharePoint-nettstedet. Du bør også angi begrensninger for antall versjoner som beholdes på SharePoint-området, og slette gamle versjoner. Dette sikrer at versjonsloggen forblir meningsfull og ikke tar opp for mye plass.

Hvis du vil ha mer avansert versjonskontroll, kan du lagre filer i et eksternt repositorium som Azure Repos og administrere endringer ved hjelp av kildekontroll.

Kildekontroll ved hjelp av et eksternt Git-repositorium

Et eksternt Git-repositorium forenkler kildekontroll av filer, noe som gjør det mulig for innholdsopprettere flere alternativer for å spore og behandle endringer. Kort sagt, innholdsopprettere kan utvikle innhold enten lokalt eller i Power BI-tjenesten, og deretter utføre og sende disse endringene til et eksternt Git-repositorium som Azure Repos

Notat

Du kan også utføre kildekontroll av innholdet uten å bruke Git-integrering. I dette scenarioet kan du fortsatt spore og behandle innholdsendringer i et eksternt Git-repositorium, men du distribuerer innhold ved hjelp av REST-API-er eller XMLA-lese-/skriveendepunkter. Hvis du vil ha mer informasjon om disse metodene for distribusjon av innhold, kan du se trinn 4: Distribuere innhold.

Diagrammet nedenfor viser en oversikt på høyt nivå over hvordan du utfører kildekontroll etter

Diagrammet beskriver følgende prosesser og komponenter.

element	beskrivelse
	Innholdsopprettere utvikler semantiske modeller og rapporter i sitt lokale miljø og lagrer disse modellene og rapportene som PBIP-filer. Innholdsopprettere kan også utvikle semantiske modeller og lagre modellmetadata.
	Når de er klare, lagrer innholdsopprettere endringene sine, som de utfører og sender til et eksternt Git-repositorium med jevne mellomrom.
	I det eksterne Git-repositoriet sporer innholdsopprettere endringer på objektnivå, noe som forenkler versjonskontroll. Innholdsopprettere kan også opprette grener for å arbeide med innhold, og slå sammen endringene til én enkelt gren ved hjelp av pull-forespørsler.
	Innholdsopprettere kan synkronisere innhold fra det eksterne repositoriet ved hjelp av Git-integrering. De kan også distribuere innhold ved hjelp av andre tilnærminger, for eksempel Azure Pipelines sammen med REST-API-ene.
	Innholdsopprettere i Fabric-arbeidsområdet ser endringene i Power BI-innhold etter at synkroniseringen eller distribusjonen er fullført. Innholdsopprettere kan redigere innhold som dataflyter eller notatblokker i arbeidsområdet. Hvis de bruker Git-integrering, kobler innholdsopprettere dette arbeidsområdet til en bestemt gren av det eksterne repositoriet.
	Innholdsopprettere kan utføre og sende endringer fra et arbeidsområde til det eksterne repositoriet ved hjelp av Git-integrering. Disse endringene kan importere elementdefinisjoner for innhold som støttes i arbeidsområdet, for eksempel dataflyter og notatblokker.

Sammendrag lagrer innholdsopprettere .pbip-filer, metadatafiler og dokumentasjon i et sentralt Azure Repos-eksternt repositorium. 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 mer avanserte alternativer for sporing og administrasjon av endringer sammenlignet med SharePoint og OneDrive. Det er viktig å opprettholde et godt kuratert, dokumentert repositorium fordi det er grunnlaget for alt innhold og samarbeid.

Vurder å bruke kildekontroll til å spore og behandle endringer i følgende scenarioer:

• Sentraliserte eller desentraliserte team oppretter og administrerer innholdet.
• Innholdsopprettere samarbeider ved hjelp av Azure DevOps.
• Innholdsopprettere er kjent med Git, kildekontrollbehandling eller DataOps-prinsipper.
• Innholdsopprettere administrerer komplekst eller viktig innhold eller forventer at innholdet skaleres og vokser i kompleksitet og viktighet.

Her er noen forutsetninger og vurderinger for å hjelpe deg med effektiv bruk av kildekontroll med Azure DevOps.

• Git: Hvis du vil utføre og sende endringer til et eksternt repositorium, må innholdsopprettere laste ned og installere Git-. 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?.
• Verktøy: Hvis du vil bruke Git, må innholdsopprettere enten bruke en kommandolinjegrensesnitt (CLI) eller en gui-klient (graphical user interface) for SCM, for eksempel Visual Studio eller Visual Studio Code.
• lisenser og tillatelser: Hvis du vil opprette og bruke et Azure Repos Git-repositorium, må innholdsopprettere ha følgende:
  • Tilgangsnivå satt til Grunnleggende (i motsetning til interessent).
  • Tilhører en organisasjon og et prosjekt.
  • Riktige repositoriumtillatelser.
• Fabric Git-integrering: Hvis du vil synkronisere innhold i et eksternt repositorium med et Microsoft Fabric-arbeidsområde, bruker innholdsopprettere Fabric Git-integrering. Dette er viktig for å spore og behandle endringer i innhold som er opprettet i Stoff-portalen, for eksempel dataflyter.

Tips

Hvis du vil legge til rette for kildekontroll med lokal utvikling, anbefaler vi at du bruker et klientprogram som Visual Studio Code. Du bruker Power BI Desktop til å utvikle innhold, og deretter kan du bruke Visual Studio Code til å utføre kildekontrollbehandling av innholdet, ved å sette opp, forplikte og sende endringer til det eksterne repositoriet.

Advarsel

Fabric Git-integrering har noen begrensninger med støttede elementer og scenarier. Sørg for at du først validerer om Fabric Git-integrering passer best til ditt spesifikke scenario, eller om du bør ta en annen tilnærming for å implementere kildekontroll.

I tillegg støttes ikke følsomhetsetiketter med Fabric Git-integrering, og eksport av elementer med følsomhetsetiketter kan være deaktivert. Hvis innholdet har følsomhetsetiketter, bør du planlegge hvordan du kan oppnå versjonskontroll samtidig som du overholder policyene for hindring av datatap.

En viktig fordel ved å bruke kildekontroll med Azure Repos er forbedret samarbeid mellom innholdsopprettere og mer tilpasning og tilsyn angående innholdsendringer og distribusjon.

Diagrammet nedenfor viser en oversikt på høyt nivå over hvordan Azure DevOps muliggjør samarbeid med kildekontroll.

Notat

Det forrige diagrammet viser ett eksempel på hvordan du samarbeider ved hjelp av Azure DevOps. Velg en fremgangsmåte som passer best til behovene og måten du arbeider på i teamet.

Diagrammet viser følgende brukerhandlinger, prosesser og funksjoner.

element	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.

De følgende avsnittene beskriver flere hensyn for effektiv bruk av kildekontroll ved hjelp av Azure DevOps og Power BI.

Viktig

Effektiv bruk av forgrening, utføringer, pull-forespørsler og flettinger er avgjørende for å dra mest nytte av kildekontrollen når du administrerer livssyklusen til Power BI-innholdet.

Bruk grener

Innholdsopprettere oppnår samarbeid ved hjelp av en forgreningsstrategi. En forgreningsstrategi gjør det mulig for individuelle innholdsopprettere å arbeide 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 beskrivende utføringsmelding. En utføringsmelding beskriver endringene som er gjort i denne utførelsen.

Når du bruker en forgreningsstrategi til å administrere stoffinnhold, bør du vurdere følgende faktorer.

• Hvilke opprettere av greninnhold bør klone for sitt eget arbeid. Hvis for eksempel disse grenene er en klone av hovedgrenen (kjent som trunk basert utvikling) eller hvis de er andre grener, for eksempel utgivelsesgrener for bestemte, planlagte versjoner av innhold.
• Om du skal begrense bestemt arbeid til distinkte innholdsutgivelser ved hjelp av utgivelsesgrener.
• Hvilke grener kobler til hvilket arbeidsområde når du bruker Fabric Git-integrasjon.

Tips

Se Ta i bruk en Git-forgreningsstrategi for spesifikk veiledning og anbefalinger om hvordan du best kan bruke en forgreningsstrategi for effektivt å legge til rette for samarbeid.

Satsvise endringer i utføringer

Når du utvikler innhold, bør opprettere regelmessig foreta endringer i grupper (eller grupper). Disse endringene bør ta for seg et bestemt arbeidselement for løsningen (for eksempel en funksjon eller et problem). Når du er klar, utfører innholdsopprettere disse trinnvise endringene.

Batching endringer på denne måten har flere fordeler.

• Det bidrar til å strukturere utvikling og gir innholdsopprettere muligheten til å se gjennom og dokumentere endringene de har gruppert.
• Det forbedrer justeringen mellom planlegging og utvikling, noe som gjør det enklere å koble funksjoner og problemer og få åpenhet om hvordan arbeidet fortsetter.
• Tekniske eiere kan lettere se gjennom pull-forespørsler fra innholdsopprettere hvis endringer er gruppert riktig og har klare utføringsmeldinger.

Når du faser og utfører endringer i Power BI-innhold, bør du vurdere følgende faktorer.

• Enten du skal iscenesette og utføre endringer fra et lokalt repositorium eller fra Fabric-arbeidsområdet.
• Plasser PBIP-filer i mapper på øverste nivå når du lagrer flere modeller eller rapporter i ett enkelt repositorium. Dette gjør det enklere å identifisere og gruppere endringer du gjør.
• Ignorer uskyldige eller uhjelpsomme metadataendringer ved hjelp av en gitignore-fil eller en GITATTRIBUTES-fil. Dette sikrer at alle endringene du utfører, er meningsfulle.

Tips

Se Lagre arbeidet med utføringer for spesifikk veiledning og anbefalinger om hvordan du kan iscenesette og forplikte arbeidet til et Git-repositorium.

Opprette pull-forespørsler for å slå sammen endringer

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.

Når du bruker pull-forespørsler til å slå sammen endringer i Power BI-innhold, bør du vurdere følgende faktorer.

• Hvilke standarder og fremgangsmåter du vil bruke til å utføre gjennomgangen, hvis noen. Du kan for eksempel bruke regler fra Best Practice Analyzer for semantiske modeller.
• Hvordan du skal se gjennom endringer i rapportmetadata, som ikke er lett å lese og forstå uten å bruke tredjepartsverktøy.
• Hvordan du løse og løse flettekonflikter.

Tips

Se Om pull-forespørsler og Slå sammen strategier og squashfletting for spesifikk veiledning og anbefalinger om hvordan du best kan bruke pull-forespørsler for å legge til rette for samarbeid ved å slå sammen endringer i innhold.

sjekkliste – Når du planlegger hvor du skal lagre filer, omfatter viktige beslutninger og handlinger:

• Velg utviklingsverktøy: Sørg for at fremgangsmåten for å utvikle innhold samsvarer med hvordan du samarbeider med andre innholdsopprettere og bruker versjonskontroll.
• Velg mellom PBIP- og PBIX-formater for modeller og rapporter: PBIP-formatet er vanligvis mer gunstig for kildekontroll, men selvbetjente brukere kan finne PBIX-filer som er enklere å bruke.
• Separat semantisk modell og rapportutvikling: Versjonskontroll er mest effektiv når du administrerer endringer for ulike elementtyper, separat. Separeringsmodell og rapportutvikling regnes som en god praksis.
• Bestem hvor mange arbeidsområder du trenger: Bruk av separate miljøer er avgjørende for at innholdslivssyklusbehandling skal lykkes. Sørg for at du har klargjort hvor mange arbeidsområder du trenger, og utfør riktig planlegging på arbeidsområdenivå.
• Bestem hvordan du implementerer versjonskontroll: Bestem deg mellom en enklere tilnærming ved hjelp av SharePoint eller OneDrive for Business, eller ved å bruke Azure DevOps til å forenkle kildekontrollen.
• Konfigurere det eksterne repositoriet: Opprett en strukturert plass i OneDrive-mappen eller Git Repo, der du lagrer innhold for å spore og behandle endringer.
• Hvis du bruker kildekontroll, konfigurerer du GITIGNORE- og GITATTRIBUTES-filer: Kontroller at du konfigurerer repositoriet slik at du bare sporer meningsfulle endringer.
• Hvis du bruker kildekontroll, definerer du forgrenings- og flettestrategier: Sørg for at du definerer klare prosesser for hvordan du konfigurerer og bruker kildekontroll til best mulig støtteutvikling. Unngå å overkomplisere prosessen. Prøv i stedet å utfylle den nåværende måten å arbeide på i utviklingsteamene dine.

Relatert innhold

I den neste artikkelen i denne serienlærer du hvordan du validerer innhold som en del av administrasjonen av innholdslivssyklusen.