Anbefalte fremgangsmåter for livssyklusadministrasjon
Denne artikkelen gir veiledning for data- og analyseopprettere som administrerer innholdet gjennom hele livssyklusen i Microsoft Fabric. Artikkelen fokuserer på bruk av Git-integrasjon for kildekontroll og distribusjonssamlebånd som et utgivelsesverktøy . For en generell veiledning om virksomhetsinnholdspublisering, virksomhetsinnholdspublisering.
Viktig
Denne funksjonen er i forhåndsvisning.
Artikkelen er delt inn i fire inndelinger:
Forberedelse av innhold – Klargjør innholdet for livssyklusbehandling.
Utvikling – Lær om de beste måtene å opprette innhold på i utviklingsfasen for utrullingssamlebånd.
Test – Forstå hvordan du bruker et testtrinn for utrullingssamlebånd til å teste miljøet.
Produksjon – Bruk produksjonsfasen for utrullingssamlebånd for å gjøre innholdet tilgjengelig for forbruk.
Forberedelse av innhold
Hvis du best vil klargjøre innholdet for pågående administrasjon gjennom hele livssyklusen, kan du se gjennom informasjonen i denne delen før deg:
Frigi innhold til produksjon.
Begynn å bruke et utrullingssamlebånd for et bestemt arbeidsområde.
Skille utvikling mellom team
Ulike team i organisasjonen har vanligvis forskjellig kompetanse, eierskap og arbeidsmetoder, selv når de arbeider på samme prosjekt. Det er viktig å sette grenser samtidig som hvert lag får sin uavhengighet til å fungere som de vil. Vurder å ha separate arbeidsområder for forskjellige team. Med separate arbeidsområder kan hver gruppe ha forskjellige tillatelser, arbeide med forskjellige repositorier for kildekontroll og sende innhold til produksjon i en annen frekvens. De fleste elementer kan koble til og bruke data på tvers av arbeidsområder, slik at det ikke blokkerer samarbeid på de samme dataene og prosjektet.
Planlegge tillatelsesmodellen
Både Git-integrering og utrullingssamlebånd krever andre tillatelser enn bare arbeidsområdetillatelsene. Les om tillatelseskravene for Git-integrering og distribusjonssamlebånd.
Hvis du vil implementere en sikker og enkel arbeidsflyt, kan du planlegge hvem som får tilgang til hver del av miljøene som brukes, både Git-repositoriet og utvikler-/test-/prod-fasene i et datasamlebånd. Noen av hensynene du må ta hensyn til, er:
Hvem skal ha tilgang til kildekoden i Git-repositoriet?
Hvilke operasjoner skal brukere med datasamlebåndtilgang kunne utføre i hvert trinn?
Hvem gjennomgår innhold i testfasen?
Skal kontrollørene for testfasen ha tilgang til datasamlebåndet?
Hvem bør overvåke distribusjon til produksjonsfasen?
Hvilket arbeidsområde tilordner du til et datasamlebånd eller kobler til git?
Hvilken gren kobler du arbeidsområdet til? Hva er policyen som er definert for denne grenen?
Deles arbeidsområdet av flere gruppemedlemmer? Bør de gjøre endringer direkte i arbeidsområdet, eller bare gjennom Pull-forespørsler?
Hvilken fase tilordner du arbeidsområdet til?
Må du gjøre endringer i tillatelsene til arbeidsområdet du tilordner?
Koble til ulike faser til ulike databaser
En produksjonsdatabase skal alltid være stabil og tilgjengelig. Det er best å ikke overbelaste det med spørringer generert av BI-opprettere for deres utvikling eller test semantiske modeller. Bygg separate databaser for utvikling og testing for å beskytte produksjonsdata og ikke overbelaste utviklingsdatabasen med hele volumet av produksjonsdata.
Bruk parametere for konfigurasjoner som endres mellom faser
Når det er mulig, kan du legge til parametere i en hvilken som helst definisjon som kan endres mellom dev/test/prod-faser. Ved hjelp av parametere kan du enkelt endre definisjonene når du flytter endringene til produksjon. Selv om det fortsatt ikke finnes noen enhetlig måte å administrere parametere på i Fabric, anbefaler vi at du bruker den på elementer som støtter alle typer parameteriseringer.
Parametere har ulike bruksområder, for eksempel definering av tilkoblinger til datakilder eller interne elementer i Fabric. De kan også brukes til å gjøre endringer i spørringer, filtre og teksten som vises for brukerne.
I utrullingssamlebånd kan du konfigurere parameterregler for å angi forskjellige verdier for hvert distribusjonstrinn.
Utvikling
Denne delen gir veiledning for å arbeide med utrullingssamlebånd og bruke til utviklingsfasen.
Sikkerhetskopiere arbeidet til et Git-repositorium
Med Git-integrering kan enhver utvikler sikkerhetskopiere arbeidet sitt ved å forplikte det til Git. For å sikkerhetskopiere arbeidet riktig i Fabric, her er noen grunnleggende regler:
Kontroller at du har et isolert miljø å arbeide i, slik at andre ikke overstyrer arbeidet ditt før det blir forpliktet. Dette betyr at du arbeider i et skrivebordsverktøy (for eksempel VS Code, Power BI Desktop eller andre), eller i et eget arbeidsområde som andre brukere ikke har tilgang til.
Forplikte deg til en gren som du opprettet, og ingen annen utvikler bruker. Hvis du bruker et arbeidsområde som redigeringsmiljø, kan du lese om hvordan du arbeider med grener.
Utfør sammen endringer som må distribueres sammen. Dette rådet gjelder for ett enkelt element eller flere elementer som er relatert til den samme endringen. Hvis du utfører alle relaterte endringer sammen, kan det hjelpe deg senere når du distribuerer til andre faser, oppretter pull-forespørsler eller tilbakestiller endringer tilbake.
Store utføringer kan nå en maksimal størrelsesgrense for utføring. Vær oppmerksom på hvor mange elementer du utfører sammen, eller den generelle størrelsen på et element. Rapporter kan for eksempel bli store når du legger til store bilder. Det er dårlig praksis å lagre store elementer i kildekontrollsystemer, selv om det fungerer. Vurder måter å redusere størrelsen på elementene på hvis de har mange statiske ressurser, for eksempel bilder.
Rulle tilbake endringer
Når du har sikkerhetskopiert arbeidet, kan det være tilfeller der du vil gå tilbake til en tidligere versjon og gjenopprette den i arbeidsområdet. Det finnes noen måter å gå tilbake til en tidligere versjon på:
Angre-knappen: Angre-operasjonen er en enkel og rask måte å gjenopprette de umiddelbare endringene du har gjort, så lenge de ikke er utført ennå. Du kan også angre hvert element separat. Les mer om angreoperasjonen .
Gå tilbake til eldre utføringer: Det er ingen direkte måte å gå tilbake til en tidligere utføring i brukergrensesnittet på. Det beste alternativet er å heve en eldre forpliktelse til å være HEAD ved hjelp av git revert eller git reset. Dette viser at det finnes en oppdatering i kildekontrollruten, og du kan oppdatere arbeidsområdet med den nye utførelsen.
Siden data ikke er lagret i Git, må du huske på at å tilbakestille et dataelement til en eldre versjon kan bryte eksisterende data og muligens kreve at du slipper dataene, eller at operasjonen mislykkes. Kontroller dette på forhånd før du tilbakestiller endringene tilbake.
Arbeide med et privat arbeidsområde
Når du vil arbeide isolert, kan du bruke et separat arbeidsområde som et isolert miljø. Les mer om hvordan du isolerer arbeidsmiljøet i arbeid med grener. Vurder følgende punkter for en optimal arbeidsflyt for deg og teamet:
Konfigurere arbeidsområdet: Før du begynner, må du kontrollere at du kan opprette et nytt arbeidsområde (hvis du ikke allerede har et), at du kan tilordne det til en Fabric-kapasitet, og at du har tilgang til data for å arbeide i arbeidsområdet.
Oppretter en ny gren: Opprett en ny gren fra hovedgrenen, slik at du har den mest oppdaterte versjonen av innholdet. Kontroller også at du kobler til riktig mappe i grenen, slik at du kan hente riktig innhold inn i arbeidsområdet.
Små, hyppige endringer: Det er en anbefalt fremgangsmåte for Git å gjøre små trinnvise endringer som er enkle å slå sammen og mindre sannsynlig å komme i konflikt. Hvis det ikke er mulig, må du sørge for å oppdatere grenen fra hoveddelen, slik at du kan løse konflikter på egen hånd først.
Konfigurasjonsendringer: Endre om nødvendig konfigurasjonene i arbeidsområdet for å hjelpe deg med å arbeide mer produktivt. Noen endringer kan omfatte tilkobling mellom elementer, eller til ulike datakilder eller endringer i parametere på et gitt element. Bare husk at alt du begår blir en del av utføringen og kan ved et uhell slås sammen til hovedgrenen.
Bruke klientverktøy til å redigere arbeidet ditt
For elementer og verktøy som støtter det, kan det være enklere å arbeide med klientverktøy for redigering, for eksempel Power BI Desktop for semantiske modeller og rapporter, VSCode for notatblokker osv. Disse verktøyene kan være ditt lokale utviklingsmiljø. Når du har fullført arbeidet, flytter du endringene til det eksterne repoet og synkroniserer arbeidsområdet for å laste opp endringene. Bare kontroller at du arbeider med den støttede strukturen for elementet du redigerer. Hvis du ikke er sikker, må du først klone et repo med innhold som allerede er synkronisert til et arbeidsområde, og deretter begynne å redigere derfra, der strukturen allerede er på plass.
Administrere arbeidsområder og grener
Siden et arbeidsområde bare kan kobles til én enkelt gren om gangen, anbefales det å behandle dette som en 1:1-tilordning. Hvis du imidlertid vil redusere arbeidsområdet det innebærer, bør du vurdere disse alternativene:
Hvis en utvikler konfigurerer et privat arbeidsområde med alle nødvendige konfigurasjoner, kan de fortsette å bruke dette arbeidsområdet for alle fremtidige forgreninger de oppretter. Når en sprint er over, slås endringene sammen og du starter en ny ny oppgave, bare bytt tilkoblingen til en ny gren på samme arbeidsområde. Du kan også gjøre dette hvis du plutselig trenger å fikse en feil midt i en sprint. Tenk på det som en arbeidskatalog på nettet.
Utviklere som bruker et klientverktøy (for eksempel VS Code, Power BI Desktop eller andre), trenger ikke nødvendigvis et arbeidsområde. De kan opprette grener og utføre endringer i grenen lokalt, sende dem til eksternt repo og opprette en pull-forespørsel til hovedgrenen, alt uten et arbeidsområde. Et arbeidsområde er bare nødvendig som et testmiljø for å kontrollere at alt fungerer i et virkelig scenario. Det er opp til deg å bestemme når det skal skje.
Duplisere et element i et Git-repositorium
Slik dupliserer du et element i et Git-repositorium:
- Kopier hele elementkatalogen.
- Endre logisk ID til noe unikt for det tilkoblede arbeidsområdet.
- Endre visningsnavnet for å skille det fra det opprinnelige elementet og unngå duplikat visningsnavnfeil.
- Oppdater eventuelt logiskE ID- og/eller visningsnavn i eventuelle avhengigheter.
Test
Denne delen gir veiledning for å arbeide med en testfase for utrullingssamlebånd.
Simulere produksjonsmiljøet
Det er viktig å se hvordan den foreslåtte endringen vil påvirke produksjonsfasen. Med et testtrinn for utrullingssamlebånd kan du simulere et reelt produksjonsmiljø for testformål. Alternativt kan du simulere dette ved å koble Git til et annet arbeidsområde.
Kontroller at disse tre faktorene er adressert i testmiljøet:
Datavolum
Bruksvolum
En lignende kapasitet som i produksjon
Når du tester, kan du bruke samme kapasitet som produksjonsfasen. Bruk av samme kapasitet kan imidlertid gjøre produksjonen ustabil under belastningstesting. Hvis du vil unngå ustabil produksjon, tester du ved hjelp av en annen kapasitet som ligner på ressursene til produksjonskapasiteten. Hvis du vil unngå ekstra kostnader, kan du bruke en kapasitet der du bare kan betale for testtiden.
Bruke distribusjonsregler med en datakilde i virkeligheten
Hvis du bruker testfasen til å simulere databruk i virkeligheten, er det best å skille utviklings- og testdatakilder. Utviklingsdatabasen skal være relativt liten, og testdatabasen bør være så lik produksjonsdatabasen som mulig. Bruk datakilderegler til å bytte datakilder i testfasen eller parametere tilkoblingen hvis den ikke fungerer gjennom utrullingssamlebånd.
Kontrollere relaterte elementer
Endringer du gjør, kan også påvirke de underordnede elementene. Under testingen må du kontrollere at endringene ikke påvirker eller bryter ytelsen til eksisterende elementer, noe som kan være avhengig av de oppdaterte.
Du kan enkelt finne relaterte elementer ved hjelp av konsekvensanalyse.
Oppdaterer dataelementer
Dataelementer er elementer som lagrer data. Elementets definisjon i Git definerer hvordan dataene lagres. Når du oppdaterer et element i arbeidsområdet, importerer vi definisjonen til arbeidsområdet og bruker det på de eksisterende dataene. Operasjonen med å oppdatere dataelementer er den samme for Git- og distribusjonssamlebånd.
Ettersom ulike elementer har forskjellige funksjoner når det gjelder å beholde data når endringer i definisjonen brukes, må du være oppmerksom når du bruker endringene. Noen fremgangsmåter som kan hjelpe deg med å bruke endringene på den sikreste måten:
Vit på forhånd hva endringene er og hva deres innvirkning kan være på de eksisterende dataene. Bruk utføringsmeldinger til å beskrive endringene som er gjort.
Hvis du vil se hvordan elementet håndterer endringen med testdata, laster du opp endringene først til et utviklings- eller testmiljø.
Hvis alt går bra, anbefales det også å sjekke det på et oppsamlingsmiljø, med virkelige data (eller så nær det som mulig), for å minimere uventet atferd i produksjonen.
Vurder den beste tidsberegningen når du oppdaterer Prod-miljøet for å minimere skaden som eventuelle feil kan forårsake for bedriftsbrukerne som bruker dataene.
Etter distribusjon tester etter distribusjon i Prod for å bekrefte at alt fungerer som forventet.
Noen endringer vil alltid bli vurdert som brudd på endringer. Forhåpentligvis vil de foregående trinnene hjelpe deg med å spore dem før produksjonen. Bygg en plan for hvordan du bruker endringene i Prod, og gjenopprett dataene for å gå tilbake til normal tilstand og minimere nedetid for forretningsbrukere.
Test appen
Hvis du distribuerer innhold til kundene gjennom en app, kan du se gjennom appens nye versjon før den er i produksjon. Siden hvert utrullingssamlebånd har sitt eget arbeidsområde, kan du enkelt publisere og oppdatere apper for utviklings- og testfaser. Når du publiserer og oppdaterer apper, kan du teste appen fra sluttbrukerens synspunkt.
Viktig
Distribusjonsprosessen inkluderer ikke oppdatering av appinnholdet eller -innstillingene. Hvis du vil bruke endringer på innhold eller innstillinger, oppdaterer du appen manuelt i den nødvendige samlebåndfasen.
Produksjon
Denne delen gir veiledning til produksjonsfasen for utrullingssamlebånd.
Administrere hvem som kan distribuere til produksjon
Fordi distribusjon til produksjon bør håndteres nøye, er det god praksis å la bare bestemte personer administrere denne sensitive operasjonen. Du vil imidlertid sannsynligvis at alle BI-opprettere for et bestemt arbeidsområde skal ha tilgang til datasamlebåndet. Bruk tillatelser for produksjonsarbeidsområde til å behandle tilgangstillatelser. Andre brukere kan ha en visningsrolle for produksjonsarbeidsområdet for å se innhold i arbeidsområdet, men ikke gjøre endringer fra Git- eller distribusjonssamlebånd.
I tillegg kan du begrense tilgangen til repo eller pipeline ved bare å aktivere tillatelser til brukere som er en del av prosessen for oppretting av innhold.
Angi regler for å sikre tilgjengelighet for produksjonstrinn
Distribusjonsregler er en effektiv måte å sikre at dataene i produksjonen alltid er tilkoblet og tilgjengelig for brukere. Når distribusjonsregler brukes, kan distribusjoner kjøre mens du har forsikring om at kunder kan se relevant informasjon uten forstyrrelser.
Kontroller at du angir produksjonsdistribusjonsregler for datakilder og parametere som er definert i semantisk modell.
Oppdater produksjonsappen
Distribusjon i et datasamlebånd gjennom brukergrensesnittet oppdaterer innholdet i arbeidsområdet. Hvis du vil oppdatere den tilknyttede appen, bruker du API-en for utrullingssamlebånd. Det er ikke mulig å oppdatere appen via brukergrensesnittet. Hvis du bruker en app for innholdsdistribusjon, må du ikke glemme å oppdatere appen etter distribusjon til produksjon, slik at sluttbrukere umiddelbart kan bruke den nyeste versjonen.
Distribuering i produksjon ved hjelp av Git-grener
Som repo fungerer som "single-source-of-truth", kan det hende at noen team ønsker å distribuere oppdateringer til forskjellige stadier direkte fra Git. Dette er mulig med Git-integrasjon, med noen få hensyn:
Vi anbefaler at du bruker utgivelsesgrener. Du må kontinuerlig endre tilkoblingen til arbeidsområdet til de nye utgivelsesgrenene før hver distribusjon.
Hvis bygg- eller utgivelsessamlebåndet krever at du endrer kildekoden, eller kjører skript i et byggmiljø før distribusjon til arbeidsområdet, vil det ikke hjelpe deg å koble arbeidsområdet til Git.
Når du har distribuert til hvert trinn, må du passe på å endre alle konfigurasjonene som er spesifikke for dette stadiet.
Hurtigrettinger til innhold
Noen ganger er det problemer i produksjonen som krever en rask løsning. Distribusjon av en løsning uten å teste den først er dårlig praksis. Derfor må du alltid implementere løsningen i utviklingsfasen og sende den til resten av utrullingsforløpsfasene. Ved å distribuere til utviklingsfasen kan du kontrollere at løsningen fungerer før du distribuerer den til produksjon. Distribusjon på tvers av datasamlebåndet tar bare noen få minutter.
Hvis du bruker distribusjon fra Git, anbefaler vi at du følger fremgangsmåtene som er beskrevet i Ta i bruk en Git-forgreningsstrategi.
Relatert innhold
Tilbakemeldinger
Kommer snart: Gjennom 2024 faser vi ut GitHub Issues som tilbakemeldingsmekanisme for innhold, og erstatter det med et nytt system for tilbakemeldinger. Hvis du vil ha mer informasjon, kan du se: https://aka.ms/ContentUserFeedback.
Send inn og vis tilbakemelding for