Planlegging av Power BI-implementering: Planlegge og utforme 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 å planlegge og utforme innhold 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.
• 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. Som beskrevet i den første artikkelen i denne serien, er administrasjon av livssyklusen for Power BI-innhold viktig for å sikre pålitelig og konsekvent levering av innhold til forretningsbrukere.

Den første fasen av innholdslivssyklusen er å planlegge og utforme innhold. Du starter vanligvis innholdslivssyklusen ved å utføre BI-løsningsplanlegging. Du samle krav for å forstå og definere problemet løsningen skal løse, og komme frem til en løsningsutforming. I løpet av denne planleggings- og utformingsfasen tar du viktige beslutninger for å forberede deg til de senere fasene.

Bildet nedenfor viser livssyklusen til Power BI-innhold, utheving av trinn én, der du planlegger og utformer innhold.

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 hensyn og beslutninger for innholdsplanlegging og utforming når de gjelder livssyklusadministrasjon.

• Hvis du vil ha mer informasjon om hvordan du effektivt planlegger og utformer en Fabric- eller Power BI-løsning, anbefaler vi at du leser løsningsplanlegging artikkelen.
• Hvis du vil ha mer informasjon om hvordan du effektivt planlegge en Power BI-overføring, anbefaler vi at du leser Power BI--serien.

Når du samler inn krav, bør du tydelig beskrive aspekter ved innholdet som påvirker din tilnærming til livssyklusbehandling. Du bør dokumentere disse aspektene som en del av løsningsplanleggingen og utformingen.

De følgende avsnittene i denne artikkelen beskriver de viktigste aspektene og vurderingene ved en løsning som motiverer din tilnærming til livssyklusbehandling etter hvert som du planlegger og utformer innholdet.

Identifisere og beskrive innholdet

Når du utformer løsningen, bør du beskrive hva innholdet er, hvem som skal opprette den, hvem som støtter den, og hvor kritisk dette innholdet er for organisasjonen. Du bør ta tak i disse faktorene under, eller etter at du er ferdig, samlekrav som en del av løsningsutformingen.

Notat

I likhet med kravene dine kan svarene på disse spørsmålene endres etter hvert som du utvikler løsningen, eller senere i livssyklusen. Når du har svart på disse spørsmålene, må du være forberedt på å evaluere dem regelmessig når du gjør endringer i innhold, eller når det skaleres i antall brukere det betjener.

Svar på følgende spørsmål om innholdet for å hjelpe deg med å ta beslutninger om livssyklusadministrasjon senere.

Hva er formatet på innholdet?

Innholdstypen, omfanget og kompleksiteten i innholdet motiverer viktige beslutninger om hvordan du skal administrere det. En enkelt rapport for en begrenset målgruppe krever for eksempel en annen tilnærming til livssyklusbehandling sammenlignet med en semantisk modell som skal brukes av hele organisasjonen og av flere forskjellige nedstrøms arbeidsbelastninger.

Svar på spørsmål som følgende for å hjelpe deg med å finne ut hvilken type innhold du skal opprette.

• Hvilke elementtyper forventer du å opprette, og hvor mange av hver? Vil du for eksempel opprette dataelementer som dataflyter eller semantiske modeller, rapportere elementer som rapporter eller instrumentbord eller en kombinasjon av begge?
• Hvordan leveres innholdet til innholdsforbrukere? Vil for eksempel forbrukere bruke dataelementer til å bygge sitt eget innhold, vil de bare vise sentraliserte rapporter eller en kombinasjon av begge?
• Hvor komplekst er innholdet? Er det for eksempel en liten prototype, eller en stor semantisk modell som omfatter flere forretningsprosesser?
• Forventer du at innholdets skala, omfang og kompleksitet vil vokse over tid? Vil for eksempel innholdet omfatte andre områder eller forretningsområder i fremtiden?
• Hvor lenge forventer du at bedriften trenger dette innholdet? Vil for eksempel dette innholdet støtte et viktig initiativ for virksomheten som har en begrenset tidslinje?

Tips

Vurder å lage et arkitektonisk diagram for å beskrive formatet på innholdet. Du kan inkludere ulike datakilder, elementtyper og innholdsforbrukere, og relasjonene mellom disse diskrete komponentene. Et arkitektonisk diagram kan bidra til å vise innholdet og kompleksiteten konsist, og det hjelper deg med å planlegge livssyklusbehandlingen. Du kan bruke ikonene Fabric og Azure-ikoner til å opprette disse diagrammene i ekstern programvare. Alternativt kan du bruke Azure Diagrams, som leveres med ikoner og tegneverktøy for å lage disse diagrammene.

Hvis du vil ha et eksempel på slike diagrammer, kan du se Power BI-implementeringsplanleggingen bruksscenariodiagrammer.

Hvem vil opprette og støtte innholdet?

Innholdsopprettere har ulike behov, ferdigheter og arbeidsflyter. Disse faktorene vil påvirke suksessen til ulike tilnærminger for livssyklusadministrasjon. Større, sentrale team med samarbeid krever ofte mer avansert livssyklusadministrasjon av innhold enn mindre team av selvbetjente opprettere.

Svar på spørsmål som følgende for å hjelpe deg med å finne ut hvem som skal opprette eller støtte innholdet.

• Hvor mange forskjellige personer forventer du å opprette dette innholdet? Vil flere innholdsopprettere samarbeide, eller er én enkelt person ansvarlig for å opprette innholdet?
• Er innholdsopprettere kjent med livssyklusbehandling og relaterte konsepter, for eksempel versjonskontroll? Forstår innholdsopprettere fordelene ved livssyklusbehandling?
• Vil innholdsoppretterne som utvikler løsningen, være de samme personene som støtter den etter distribusjon?
• Har innholdsopprettere eller team eksisterende fremgangsmåter for livssyklusadministrasjon på plass for å støtte eksisterende løsninger?
• Bruker innholdsopprettere for øyeblikket administrasjonsverktøy for livssyklus, for eksempel Azure DevOps?

Viktig

Sørg for at du tydelig dokumenterer hvem som er ansvarlig for å opprette innhold, og hvem som støtter det når det er distribuert til produksjon. Involver alle disse personene i planleggingen av innholdslivssyklusbehandling.

Hva er viktigheten av innholdet?

Avhengig av hvor viktig innholdet er for bedriften, vil du ta forskjellige avgjørelser om hvordan du administrerer det. Forretningskritisk innhold krever mer robuste fremgangsmåter for behandling av innholdslivssyklus for å sikre kvalitet og redusere mulige forstyrrelser.

Svar på spørsmål som følgende for å hjelpe deg med å finne ut om innholdet er kritisk.

• Hvor kritisk er dette innholdet for virksomheten? Hvor presserende er forespørselen om å utvikle den?
• Vil forretningskritiske beslutninger eller handlinger bli gjort fra informasjon fra dette innholdet?
• Hvor bredt forventer du å distribuere dette innholdet (fra hele organisasjonen til et begrenset lokalt team)?
• Vil ledere eller andre strategiske beslutningstakere stole på dette innholdet for sitt arbeid?
• Hva er virkningen av dette innholdet? Hvis for eksempel innholdet plutselig ikke er tilgjengelig, hvilke forretningsmessige konsekvenser vil skje, for eksempel tapt omsetning eller avbrutte forretningsprosesser?

Når du har identifisert og beskrevet innholdet du skal opprette, bør du bestemme hvordan innholdsopprettere skal samarbeide.

Bestem hvordan innholdsopprettere skal samarbeide

Etter hvert som en løsning øker i omfang og kompleksitet, kan det bli nødvendig for flere innholdsopprettere og eiere å arbeide i samarbeid. Når du oppretter komplekse løsninger, anbefaler vi at du bruker effektive verktøy som bidrar til å strukturere, administrere og støtte samarbeid. Det finnes mange måter å samarbeide på når du produserer Power BI-innhold, for eksempel ved hjelp av Microsoft Teams eller Azure DevOps.

Tips

Selv når innholdsopprettere arbeider uavhengig, kan de fortsatt dra nytte av planlegging og strukturering av arbeidet sitt ved hjelp av verktøy som Microsoft Teams og Azure DevOps.

Microsoft Teams

For mindre eller enklere prosjekter kan innholdsopprettere samarbeide ved hjelp av Microsoft Teams.

Ved hjelp av Microsoft Teams strukturerer innholdsopprettere kommunikasjonen, planleggingen og arbeidet i team og kanaler. Microsoft Teams er ofte et godt valg for enklere samarbeidsscenarioer. Desentraliserte team som produserer innhold for en begrenset målgruppe, kan for eksempel bruke dokumentbiblioteker til lagring av filer og versjonskontroll. De kan også benytte seg av andre integrerte verktøy og tjenester.

Tips

Vi anbefaler at du bruker Microsoft Teams til å legge til rette for effektiv administrasjon av innholdslivssyklus i selvbetjente scenarioer med desentralisert innholdslevering.

Hvis du vil samarbeide og kommunisere i Microsoft Teams, bruker du støttetjenester gjennom hele livssyklusen til Power BI-innholdet.

• Planner: Innholdseiere kan bruke Planner til å opprette planer, som de bruker til å spore oppgaver og omfangsinnhold. Oppgaver kan beskrive problemer, feil eller funksjoner i løsningen og tilsvarende interessenter.
• SharePoint-: Innholdsopprettere kan lagre og behandle filer i et Microsoft Teams-dokumentbibliotek eller tilkoblet område for hver kanal. Innholdsfiler som er lagret i SharePoint, kan bruke versjonskontroll til å spore og behandle innholdsendringer. Hvis du vil ha mer informasjon om sporing og administrasjon av endringer ved hjelp av SharePoint, kan du se trinn 2: Utvikle innhold og behandle endringer.
• Godkjenninger: Innholdsopprettere og eiere kan konfigurere og bruke arbeidsflyter til å godkjenne innholdsendringer eller utgivelser etter gjennomgang.
• Fabric og Power BI: Innholdsopprettere og eiere kan få tilgang til Fabric-portalen fra Microsoft Teams. Derfra kan de administrere eller diskutere innhold og legge til nyttige rapporter i faner i Teams-kanaler.
• Andre integreringer: Innholdsopprettere kan benytte seg av andre Microsoft- eller tredjepartstjenester som integreres med Microsoft Teams, slik at de passer best til deres foretrukne arbeidsflyt og behov.

Vi anbefaler at du definerer en strukturert prosess for hvordan innholdsopprettere skal bruke Microsoft Teams til å samarbeide. Kontroller at du bestemmer:

• Slik administrerer du tilgang til team og kanaler.
• Hvem som er ansvarlig for å administrere team og kanaler.
• Hvordan arbeid er begrenset og organisert i distinkte team, kanaler og planer.
• Slik bør innholdsopprettere bruke et dokumentbibliotek til å organisere filer og spore og behandle endringer. For eksempel hvordan du organiserer dokumentbiblioteket og om innholdsopprettere skal sjekke inn og sjekke ut filer.
• Om innholdsopprettere skal bruke OneDrive Refresh til automatisk å publisere Power BI Desktop-filer (PBIX).
• Slik løses filsynkroniseringskonflikter.
• Når du skal arkivere og fjerne filer fra et dokumentbibliotek som ikke lenger er relevant.

Azure DevOps

Innholdsopprettere og eiere kan også kommunisere og samarbeide i en sentral, organisert hub ved hjelp av 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.

Ved hjelp av Azure DevOps bruker innholdsopprettere prosjekter til å strukturere kommunikasjon, planlegging og arbeid. I tillegg kan innholdsopprettere organisere behandling av innholdslivssyklus fra Azure DevOps ved å utføre kildekontroll, validering og distribusjon. Kildekontroll er prosessen med å administrere mer detaljerte endringer i innholdskode og metadata.

Azure DevOps er ofte et godt valg for mer avanserte samarbeidsscenarioer, fordi det finnes støttetjenester og alternativer for å organisere oppretting og distribusjon av innhold.

Tips

Vi anbefaler at du bruker Azure DevOps til å hjelpe deg med effektiv administrasjon av innholdslivssyklus i bedriftsscenarioer med sentralisert innholdslevering. Samarbeid ved hjelp av Azure DevOps eller lignende verktøy foretrekkes i større eller mer komplekse scenarioer over samarbeid ved hjelp av Microsoft Teams eller SharePoint. Det er fordi det finnes flere verktøy og alternativer som er tilgjengelige for å legge til rette for mer robust samarbeid og automatisering.

Vi anbefaler at du definerer en strukturert prosess for hvordan innholdsopprettere skal bruke Azure DevOps til å samarbeide. Kontroller at du bestemmer:

• Hvordan arbeid er omfangsområder og hvordan innholdsgrener opprettes, navngis og brukes.
• Hvordan forfattere grupperer og utfører endringer og beskriver dem med utføringsmeldinger.
• Hvem som er ansvarlig for å gjennomgå og godkjenne endringer ved hjelp av pull-forespørsler.
• Hvordan du henter forespørsler om flettekonflikter, løses og hvem som løser dem.
• Hvordan endringer i ulike grener skal 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 kan rulles tilbake.

Notat

Du kan også bruke Microsoft Teams sammen med Azure DevOps fordi det finnes ulike måter å integrere disse tjenestene på. Du kan for eksempel vise og administrere Azure Boards og overvåke hendelser i Azure Pipelines fra Microsoft Teams.

Det viktigste er at du bruker verktøy og tjenester som tilrettelegger for samarbeid for deg, og som passer best til teamets behov og måten de fungerer på.

Når du har bestemt deg for om og hvordan innholdsopprettere skal samarbeide, bør du bestemme hvor du skal lagre filene dine. Mange av disse filene lagres der du velger å samarbeide.

Bestem hvor filer skal lagres

Når du oppretter innhold, produserer du vanligvis ulike filtyper. Det er viktig å bestemme hvor disse filene skal lagres, slik at du effektivt kan administrere dem.

Tips

Lagre filer der de kan åpnes av flere gruppemedlemmer, og der endringer enkelt kan spores (kjent som versjonskontroll). Denne fremgangsmåten sikrer at avgang av et gruppemedlem eller tap av en fil ikke fører til forstyrrelser.

Filtypene du må lagre, inkluderer ofte:

• innholdsfiler: Filer som inneholder innholdsdataene eller metadataene. Innholdsfiler med data som PBIX- og Power BI Project-filer (PBIP) inneholder sensitiv informasjon. Lagre innholdsfiler på et sikkert sted som bare er tilgjengelig for dem som trenger tilgang til dem. Du bør også lagre innholdsfiler på en plassering som støtter versjonskontroll, for eksempel et dokumentbibliotek i Microsoft Teams eller et Git-repositorium i Azure DevOps. Eksempler på innholdsfiler inkluderer:
  • Power BI Desktop-filer (PBIX)
  • Power BI Project-filer (PBIP)
  • Paginerte rapportfiler i Power BI (RDL)
  • Modellmetadatafiler (.bim eller TMDL)
  • Dataflytmetadatafiler (.json)
• datakildefiler: Filer som forbrukes av dataelementer som semantiske modeller eller dataflyter. Innhold er direkte avhengig av datakildefiler, så det er viktig å vurdere nøye hvor de er lagret, fordi fjerning av dem vil føre til feil ved dataoppdatering. I tillegg kan disse filene inneholde sensitiv informasjon. Så lagre datakildefiler i et sikkert, pålitelig og pålitelig miljø som har begrenset tilgang av andre personer. Eksempler på datakildefiler kan omfatte:
  • Strukturerte datakilder, for eksempel Excel-arbeidsbøker, Parquet- eller CSV-filer.
  • Halvstrukturerte datakilder, for eksempel JSON- eller XML-filer.
  • Ustrukturerte datakilder, for eksempel bilder som du importerer til rapporter.
• støttefiler: Filer som støtter oppretting eller administrasjon av innhold, men som ikke kreves for at det skal fungere. Støttefiler bør lagres på en plassering som støtter versjonskontroll, og der andre verktøy og innholdsopprettere kan få tilgang til dem. Eksempler på støttefiler kan omfatte:
  • Regler for anbefalte fremgangsmåter (.json) filer.
  • Power BI-temafiler (.json).
  • Kildekodefiler for innhold og spørringer.
  • Egendefinerte visualiseringsfiler (PBIVIZ).
• Maler og dokumentasjon: Filer som hjelper deg med å opprette selvbetjent innhold eller beskrive eksisterende innhold. Maler og dokumentasjon skal være lett tilgjengelig for personer som trenger å bruke dem. Eksempler på maler og dokumentasjon kan omfatte:
  • Power BI-malfiler (PBIT).
  • Visualiseringsmaler og eksempelrapporter.
  • Løsningsutforminger og dokumentasjon.
  • Løsningsplanlegging og veikart.
  • Brukerforespørsler og løsningsproblemer.

Forsiktighet

Enkelte innholdsfiler som PBIX- og PBIP-filer kan inneholde sensitive data som er importert fra datakilder. I tillegg kan metadatafiler som TMDL- eller PBIT-filer også inneholde sensitiv informasjon. Sørg for at du tar de nødvendige forholdsregler for å lagre disse filene på sikre plasseringer, og at du praktiserer effektiv hindring av datatap.

Du har ulike alternativer for lagring av filer. Kontroller at du velger riktig plassering, avhengig av filtype, innhold og hvordan den skal brukes.

SharePoint Online eller OneDrive

En vanlig løsning for lagring av filer er å bruke SharePoint- nettsteder. SharePoint er allment tilgjengelig for de fleste brukere og er svært integrert med både Power BI og andre Microsoft 365-programmer, for eksempel Microsoft Teams. I tillegg har den innebygde versjonskontroll, noe som gjør det praktisk å lagre de fleste filtyper. Med versjonskontroll kan du vise og administrere ulike lagrede versjoner av en fil.

Når du lagrer filer i SharePoint, bør du vurdere følgende punkter.

• organization: Sørg for at du opprettholder en konsekvent og logisk struktur, slik at det er enkelt å finne bestemte filer. Bruk gode navnekonvensjoner, organiser filer i mapper og arkivfiler som ikke lenger er relevante for pågående prosjekter.
• OneDrive-oppdatering: Du kan koble en publisert semantisk modell eller rapport til en PBIX-fil som er lagret på et SharePoint- eller OneDrive for Business-nettsted (også kalt OneDrive for jobb eller skole). Med denne fremgangsmåten trenger du ikke lenger å publisere den semantiske modellen for å få endringer i kraft. I stedet er endringene synlige etter en automatisk OneDrive-oppdatering, som skjer hver time. Selv om det er praktisk, vær oppmerksom på at denne tilnærmingen kommer med noen advarsler og utfordringer. Når ting går, kan det ikke lett reverseres.
• forhåndsvisningsrapporter: I SharePoint er det mulig å vise Power BI-rapporter uten å måtte installere Power BI Desktop eller laste ned PBIX-filen lokalt. Når du åpner rapporter på denne måten, vises de i nettleseren. Denne funksjonen kan være et praktisk alternativ til å vise rapporter fra Fabric-portalen. Det er aktivert som standard i Fabric-leierinnstillingene.

Tips

Når du samarbeider ved hjelp av Microsoft Teams, bør du vurdere å lagre filer i kanaldokumentbiblioteket. Denne fremgangsmåten bidrar til å sentralisere filer og forenkler samarbeid.

Vurder å lagre følgende filtyper i SharePoint.

• maler og dokumentasjon: Lagre maler og dokumentasjon i SharePoint når du ikke har en eksisterende lagringsløsning. SharePoint er ideelt for disse filene fordi du kan gi tilgang til andre og administrere filer uten komplisert oppsett eller prosesser.
• støttefiler: Lagre støttefiler i SharePoint når du ikke har en eksisterende lagringsløsning. Noen støttefiler (for eksempel Power BI-tema .json filer for rapporter) kan imidlertid være bedre lagret i et versjonskontrollsystem som gjør det mulig å vise og administrere lagrede endringer.
• innholdsfiler: Lagre innhold i SharePoint når det ikke er viktig for bedriften, eller når du ikke har tilgang til et eksternt repositorium, for eksempel Azure Repos.
• datakilder: Lagre datakilder i SharePoint bare når de er små i størrelse og kompleksitet. Øvelsesdisiplin når du bruker SharePoint til å lagre datakildefiler. Vurder andre mulige alternativer, for eksempel OneLake.

Forsiktighet

Ikke bruk SharePoint som et alternativ til en riktig dataarkitektur. Selv om lagring av datakildefiler i SharePoint kan være praktisk i noen begrensede scenarier, skaleres ikke denne tilnærmingen når du har større, mer komplekse datakilder, eller når du trenger lavere ventetid for data.

Advarsel

Ikke bruk personlige filsystemer eller personlige OneDrive-kontoer til å lagre filer. Hvis eieren forlater organisasjonen, vil ikke disse filene lenger være tilgjengelige.

OneLake

Hvis du har en Fabric-kapasitet, kan OneLake være et godt valg for å lagre datakildefiler. Du kan laste opp eller synkronisere filer til OneLake ved hjelp av OneLake File Explorer, der de kan transformeres til tabeller for bruk i nedstrøms arbeidsbelastninger som Power BI. Hvis du vil ha større eller jevnlig oppdaterte datakilder, kan du laste inn filer til OneLake automatisk ved hjelp av Fabric Data Factory eller andre programmer som bruker Azure Data Lake Storage (ADLS) Gen2 API eller Azure Storage Python SDK.

Forsiktighet

Handlinger som å laste opp eller laste ned filer fra OneLake bruke fabric-kapasitetsenheter. Du bør overvåke kapasitetsmåledata og iverksette tiltak for å unngå belastning på kapasiteten forårsaket av unødvendig flytting av store filer.

I tillegg er filer som brukes av brukere med OneLake File Explorer, sårbare for utilsiktede endringer eller tap. Vi anbefaler at du unngår å bruke OneLake File Explorer for forretningskritiske løsninger.

Advarsel

OneLake File Explorer har flere viktige begrensninger og hensyn. OneLake støtter for eksempel ikke versjonskontroll for filer, for eksempel SharePoint eller OneDrive. Ta hensyn til disse hensynene og begrensningene når du bestemmer deg for hvor du skal lagre filer.

Tips

Når du lagrer data i OneLake, bør du vurdere å aktivere forretningskontinuitet og nødgjenoppretting (BCDR) for å redusere risikoen for tap av data. Når BCDR er aktivert, dupliseres og lagres dataene i to forskjellige geografiske områder, i henhold til Azures standard områdesammenkoblinger.

Eksternt repositorium

Innholdsopprettere kan utføre og lagre arbeid fra sin lokale maskin til et eksternt repositorium– for eksempel en Azure Repos Git-repositorium – med jevne mellomrom under utvikling. Et eksternt repositorium inneholder den nyeste versjonen av løsningen, og den er tilgjengelig for hele utviklingsteamet. Vanligvis forenkler et eksternt repositorium mer avanserte fremgangsmåter for livssyklusadministrasjon enn å bruke Teams, SharePoint eller OneDrive. Dette er fordi innholdsopprettere kan dra nytte av mer avanserte alternativer for å samarbeide på filer ved hjelp av et eksternt repositorium, eller spore og behandle filendringer. Innholdsopprettere kan for eksempel arbeide på sin egen gren av det eksterne repositoriet for å gjøre endringer, og be om å slå sammen disse endringene til hovedgrenen når de er klare.

Vurder å lagre følgende filtyper i et eksternt repositorium.

• Maler og dokumentasjon: Lagre maler og dokumentasjon i et eksternt repositorium når du administrerer prosjektet med relaterte tjenester som Azure DevOps.
• støttefiler: Lagre støttefiler i et eksternt repositorium når en er tilgjengelig for enkel sporing og behandling av endringer.
• innholdsfiler: Lagre innhold i et eksternt repositorium når det er viktig for bedriften, eller du har tenkt å samarbeide med andre utviklere om det samme innholdet. Et eksternt repositorium er ideelt for sporing av innholdsendringer og tilrettelegging av samarbeid.

Tips

Når du bruker et eksternt repositorium, bør du vurdere å lagre Power BI-rapporter og semantiske modeller som Power BI Desktop-prosjekter (PBIP)-filer i stedet for PBIX-filer. Det er fordi lagrede endringer ikke kan identifiseres i en PBIX-fil.

Ingen filer: Innhold opprettet i Stoff-portalen

Innholdsopprettere kan redigere innhold direkte i Stoff-portalen. I dette scenarioet fungerer de vanligvis ikke direkte med innholdsfiler. Du bør vanligvis bare redigere innhold i Stoff-portalen når elementtypene ikke kan opprettes andre steder (for eksempel dataflyter, instrumentbord eller målstyringer). Du kan også redigere rapporter og semantiske modeller i Stoff-portalen når du ikke har tilgang til en Windows-maskin, og derfor ikke kan bruke Power BI Desktop. Hvis du vil ha mer informasjon, kan du se Brukerverktøy og enheter.

Forsiktighet

Du kan ikke laste ned noe innhold som er opprettet i Stoff-portalen, som en fil. Rapporter som er opprettet i Fabric-portalen, kan for eksempel ikke lastes ned som PBIX-filer.

Når du redigerer innhold i Stoff-portalen, bør du i stedet bruke Fabric API-er eller Git-integrering for å sikkerhetskopiere innholdsdefinisjoner. Når du sikkerhetskopierer innholdsdefinisjoner, reduserer du forstyrrelser hvis innholdet utilsiktet blir slettet eller utilsiktet endret. Hvis innholdet ved et uhell slettes eller endres, kan du erstatte det ved hjelp av sikkerhetskopieringen.

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

• Gjennomføre løsningsplanlegging: Samle inn forretningskrav og tekniske krav for å forstå problemet innholdet vil løse, og for å utforme hvordan dette innholdet vil løse problemet.
• Identifisere hvem som skal opprette innholdet: Avhengig av arbeidsflyten, ferdighetene og behovene til den individuelle innholdsoppretteren, kan det være nødvendig med ulike tilnærminger til livssyklusbehandling.
• Identifisere om flere innholdsopprettere må samarbeide: Kontroller at opprettere av samarbeid bruker filtyper som støtter versjonskontroll, for eksempel PBIP-filer.
• Bestem hvordan innholdsopprettere skal samarbeide: Bestem hvor avansert samarbeidet blir. I tillegg kan du bestemme hvordan du vil legge til rette for dette samarbeidet, for eksempel ved hjelp av Microsoft Teams eller Azure DevOps.
• Konfigurere samarbeidsverktøy: Kontroller at du utfører det nødvendige førstegangsoppsettet for løsningen eller prosjektet. Ta viktige avgjørelser om hvordan du skal administrere samarbeid ved hjelp av disse verktøyene.
• Lagre datakildefiler i SharePoint eller OneLake: Lagre små, enkle datakildefiler i SharePoint. Ellers kan du bruke OneLake eller ADLSGen2 (hvis de er tilgjengelige) i stedet.
• Lagre innhold og støttefiler i SharePoint eller et eksternt repositorium: For enklere, mindre prosjekter bruker du SharePoint for de fleste filer hvis det er organisert, og du praktiserer god tilgangsadministrasjon. For større miljøer eller når parallellt samarbeid er nødvendig, bør du vurdere å bruke et eksternt repositorium, som vil gi detaljert synlighet av innholdsendringer.
• Lagre maler og dokumentasjon i SharePoint: Sørg for at maler og dokumentasjon er enkle for andre å finne, bruke og forstå.
• Plan for utvikling og distribusjon: Hvis du vil avslutte denne første fasen, utfører du spesifikk planlegging for å adressere viktige områder og utføre første oppsett. Opprett for eksempel verktøy og test datakildetilkoblinger.

Relatert innhold

I den neste artikkelen i denne serienlærer du hvordan du utvikler innhold og administrerer endringer som en del av administrasjonen av innholdslivssyklusen.