Bedste praksis for administration af livscyklus

Denne artikel indeholder en vejledning til oprettere af data og analyser, der administrerer deres indhold i hele livscyklussen i Microsoft Fabric. I artiklen fokuseres der på brugen af Git-integration til kildekontrol og udrulningspipelines som et udgivelsesværktøj. Du kan få en generel vejledning i publicering af virksomhedsindhold, Enterprise-indholdsudgivelse.

Vigtigt

Denne funktion er en prøveversion.

Artiklen er opdelt i fire afsnit:

  • Indholdsforberedelse – Forbered dit indhold til livscyklusstyring.

  • Udvikling – Få mere at vide om de bedste måder at oprette indhold på i udviklingsfasen for udrulningspipelines.

  • Test – Forstå, hvordan du bruger en testfase for udrulningspipelines til at teste dit miljø.

  • Produktion – Udnyt produktionsfasen for udrulningspipelines for at gøre dit indhold tilgængeligt til forbrug.

Indholdsforberedelse

Hvis du vil forberede dit indhold til løbende administration i hele dens livscyklus, skal du gennemse oplysningerne i dette afsnit før dig:

  • Udgiv indhold til produktion.

  • Begynd at bruge en udrulningspipeline til et bestemt arbejdsområde.

Adskil udvikling mellem teams

Forskellige teams i organisationen har som regel forskellig ekspertise, ejerskab og arbejdsmetode, selv når de arbejder på det samme projekt. Det er vigtigt at sætte grænser og samtidig give hvert team deres uafhængighed til at arbejde, som de vil. Overvej at have separate arbejdsområder til forskellige teams. Med separate arbejdsområder kan hvert team have forskellige tilladelser, arbejde med forskellige lagre af kildekontrol og sende indhold til produktion i en anden kadence. De fleste elementer kan oprette forbindelse til og bruge data på tværs af arbejdsområder, så det blokerer ikke samarbejde om de samme data og projekter.

Planlæg din tilladelsesmodel

Både Git-integrations- og udrulningspipelines kræver andre tilladelser end tilladelserne til arbejdsområdet. Læs om tilladelseskravene til Git-integrations - og udrulningspipelines.

Hvis du vil implementere en sikker og nem arbejdsproces, skal du planlægge, hvem der får adgang til hver del af de miljøer, der bruges, både Git-lageret og udviklings-/test-/prod-faserne i en pipeline. Nogle af de overvejelser, der skal tages hensyn til, er:

  • Hvem skal have adgang til kildekoden i Git-lageret?

  • Hvilke handlinger skal brugere med pipelineadgang kunne udføre i hver fase?

  • Hvem gennemser indhold i testfasen?

  • Skal korrekturlæserne af testfasen have adgang til pipelinen?

  • Hvem skal styre udrulningen til produktionsfasen?

  • Hvilket arbejdsområde tildeler du til en pipeline eller opretter forbindelse til Git?

  • Hvilken forgrening opretter du forbindelse mellem arbejdsområdet og? Hvad er politikken defineret for den pågældende forgrening?

  • Deles arbejdsområdet af flere teammedlemmer? Skal de foretage ændringer direkte i arbejdsområdet eller kun via Pull-anmodninger?

  • Hvilken fase tildeler du arbejdsområdet til?

  • Har du brug for at foretage ændringer af tilladelserne for det arbejdsområde, du tildeler?

Forbind forskellige faser til forskellige databaser

En produktionsdatabase skal altid være stabil og tilgængelig. Det er bedst ikke at overbelaste den med forespørgsler, der er genereret af BI-oprettere til deres udviklings- eller test semantiske modeller. Opret separate databaser til udvikling og test for at beskytte produktionsdata og ikke overbelaste udviklingsdatabasen med hele mængden af produktionsdata.

Brug parametre til konfigurationer, der ændres mellem faser

Når det er muligt, skal du føje parametre til en hvilken som helst definition, der kan ændres mellem udviklings-/test-/prod-faser. Brug af parametre hjælper dig med nemt at ændre definitionerne, når du flytter dine ændringer til produktion. Selvom der stadig ikke er nogen samlet måde at administrere parametre på i Fabric, anbefaler vi, at du bruger den på elementer, der understøtter enhver form for parameterisering. Parametre har forskellige anvendelsesmuligheder, f.eks. definition af forbindelser til datakilder eller til interne elementer i Fabric. De kan også bruges til at foretage ændringer af forespørgsler, filtre og den tekst, der vises for brugerne.
I udrulningspipelines kan du konfigurere parameterregler for at angive forskellige værdier for hver udrulningsfase.

Udvikling

Dette afsnit indeholder en vejledning i at arbejde med udrulningspipelines og bruge egnet til din udviklingsfase.

Sikkerhedskopiér dit arbejde i et Git-lager

Med Git-integration kan alle udviklere sikkerhedskopiere deres arbejde ved at bruge det i Git. Her er nogle grundlæggende regler for at sikkerhedskopiere dit arbejde korrekt i Fabric:

  • Sørg for, at du har et isoleret miljø at arbejde i, så andre ikke tilsidesætter dit arbejde, før det bliver bekræftet. Det betyder, at du arbejder i et Desktop-værktøj (f.eks . VS Code, Power BI Desktop eller andre) eller i et separat arbejdsområde, som andre brugere ikke har adgang til.

  • Bekræft til en forgrening, som du har oprettet, og ingen anden udvikler bruger. Hvis du bruger et arbejdsområde som et oprettelsesmiljø, kan du læse om at arbejde med forgreninger.

  • Bekræft ændringer, der skal installeres sammen. Dette råd gælder for et enkelt element eller flere elementer, der er relateret til den samme ændring. Hvis du sender alle relaterede ændringer sammen, kan det hjælpe dig senere, når du udruller til andre faser, opretter pullanmodninger eller gendanner ændringer.

  • Store bekræftelser kan ramme en maksimumgrænse for bekræftelsesstørrelsen. Vær opmærksom på antallet af elementer, du har bekræftet sammen, eller den generelle størrelse af et element. Rapporter kan f.eks. blive store, når du tilføjer store billeder. Det er forkert at gemme elementer i store størrelser i versionsstyringssystemer, selvom det fungerer. Overvej måder at reducere størrelsen på dine elementer på, hvis de har mange statiske ressourcer, f.eks. billeder.

Annullerer ændringer

Når du har sikkerhedskopiere dit arbejde, kan der være tilfælde, hvor du vil vende tilbage til en tidligere version og gendanne den i arbejdsområdet. Der er et par måder at vende tilbage til en tidligere version:

  • Knappen Fortryd: Handlingen Fortryd er en nem og hurtig måde at gendanne de øjeblikkelige ændringer, du har foretaget, så længe de endnu ikke er bekræftet. Du kan også fortryde hvert element separat. Læs mere om fortrydelseshandlingen.

  • Vend tilbage til ældre bekræftelser: Der er ingen direkte måde at gå tilbage til en tidligere bekræftelse på i brugergrænsefladen. Den bedste mulighed er at fremhæve en ældre forpligtelse til at være HEAD ved hjælp af git revert eller git reset. Hvis du gør dette, kan du se, at der er en opdatering i ruden til kildekontrol, og du kan opdatere arbejdsområdet med den nye bekræftelse.

Da data ikke er gemt i Git, skal du være opmærksom på, at hvis du vender tilbage til en ældre version, kan det ødelægge de eksisterende data og muligvis kræve, at du slipper dataene, eller at handlingen mislykkes. Kontrollér dette på forhånd, før du vender tilbage til ændringerne.

Arbejde med et "privat" arbejdsområde

Når du vil arbejde isoleret, skal du bruge et separat arbejdsområde som et isoleret miljø. Læs mere om at isolere dit arbejdsmiljø i arbejdet med forgreninger. Hvis du vil have en optimal arbejdsproces for dig og teamet, skal du overveje følgende punkter:

  • Konfiguration af arbejdsområdet: Før du starter, skal du sørge for at oprette et nyt arbejdsområde (hvis du ikke allerede har et), at du kan tildele det til en Fabric-kapacitet, og at du har adgang til data for at arbejde i dit arbejdsområde.

  • Oprettelse af en ny forgrening: Opret en ny forgrening fra hovedforgreningen , så du har den nyeste version af dit indhold. Sørg også for at oprette forbindelse til den korrekte mappe i forgreningen, så du kan hente det rigtige indhold ind i arbejdsområdet.

  • Små, hyppige ændringer: Det er bedste praksis i Git at foretage små trinvise ændringer, der er nemme at flette og mindre tilbøjelige til at komme i konflikt. Hvis det ikke er muligt, skal du sørge for at opdatere din forgrening fra main, så du kan løse konflikter på egen hånd først.

  • Konfigurationsændringer: Hvis det er nødvendigt, kan du ændre konfigurationerne i dit arbejdsområde for at hjælpe dig med at arbejde mere produktivt. Nogle ændringer kan omfatte forbindelse mellem elementer eller til forskellige datakilder eller ændringer af parametre for et bestemt element. Husk blot, at alt, hvad du har bekræftet, bliver en del af bekræftelsen og ved et uheld kan flettes med hovedgrenen.

Brug klientværktøjer til at redigere dit arbejde

For elementer og værktøjer, der understøtter det, kan det være nemmere at arbejde med klientværktøjer til oprettelse, f.eks . Power BI Desktop til semantiske modeller og rapporter, VSCode til notesbøger osv. Disse værktøjer kan være dit lokale udviklingsmiljø. Når du har fuldført dit arbejde, skal du overføre ændringerne til fjern-lageret og synkronisere arbejdsområdet for at uploade ændringerne. Du skal blot sørge for, at du arbejder med den understøttede struktur for det element, du opretter. Hvis du ikke er sikker, skal du først klone et lager med indhold, der allerede er synkroniseret til et arbejdsområde, og derefter begynde at oprette derfra, hvor strukturen allerede er på plads.

Administration af arbejdsområder og forgreninger

Da et arbejdsområde kun kan forbindes til en enkelt forgrening ad gangen, anbefales det at behandle dette som en 1:1-tilknytning. Men hvis du vil reducere mængden af arbejdsområder, det medfører, skal du overveje disse muligheder:

  • Hvis en udvikler konfigurerer et privat arbejdsområde med alle de påkrævede konfigurationer, kan de fortsætte med at bruge dette arbejdsområde til alle fremtidige forgreninger, de opretter. Når en sprint er forbi, flettes dine ændringer, og du starter en ny ny opgave. Du skal blot skifte forbindelsen til en ny forgrening i det samme arbejdsområde. Du kan også gøre dette, hvis du pludselig har brug for at rette en fejl midt i en sprint. Tænk på det som en arbejdsmappe på internettet.

  • Udviklere, der bruger et klientværktøj (f.eks. VS Code, Power BI Desktop eller andre), behøver ikke nødvendigvis et arbejdsområde. De kan oprette forgreninger og sende ændringer til den pågældende forgrening lokalt, sende dem til fjern-lageret og oprette en pullanmodning til hovedgrenen, alt sammen uden et arbejdsområde. Et arbejdsområde er kun nødvendigt som et testmiljø for at kontrollere, at alt fungerer i et scenarie i det virkelige liv. Det er op til dig at beslutte, hvornår det skal ske.

Dupliker et element i et Git-lager

Sådan duplikerer du et element i et Git-lager:

  1. Kopiér hele elementmappen.
  2. Skift logicalId til noget entydigt for det forbundne arbejdsområde.
  3. Skift det viste navn for at skelne det fra det oprindelige element og for at undgå dublerede fejl i vist navn.
  4. Hvis det er nødvendigt, skal du opdatere logicalId og/eller viste navne i alle afhængigheder.

Test

Dette afsnit indeholder en vejledning i, hvordan du arbejder med en testfase for udrulningspipelines.

Simuler dit produktionsmiljø

Det er vigtigt at se, hvordan din foreslåede ændring påvirker produktionsfasen. En testfase for udrulningspipelines giver dig mulighed for at simulere et reelt produktionsmiljø til testformål. Du kan også simulere dette ved at oprette forbindelse mellem Git og et andet arbejdsområde.

Sørg for, at disse tre faktorer er behandlet i dit testmiljø:

  • Datamængde

  • Forbrugsvolumen

  • En kapacitet, der svarer til produktionskapaciteten

Når du tester, kan du bruge den samme kapacitet som produktionsfasen. Hvis du bruger den samme kapacitet, kan det dog gøre produktionen ustabil under belastningstest. Hvis du vil undgå ustabil produktion, skal du teste ved hjælp af en anden kapacitet, der ligner produktionskapaciteten i ressourcer. Hvis du vil undgå ekstra omkostninger, skal du bruge en kapacitet, hvor du kun kan betale for testtiden.

A diagram showing a deployment pipeline with a test environment simulating the production environment.

Brug udrulningsregler med en datakilde i det virkelige liv

Hvis du bruger testfasen til at simulere brug af data i det virkelige liv, er det bedst at adskille udviklings- og testdatakilderne. Udviklingsdatabasen skal være relativt lille, og testdatabasen skal være så lig produktionsdatabasen som muligt. Brug datakilderegler til at skifte datakilder i testfasen eller parameterisere forbindelsen, hvis den ikke fungerer via udrulningspipelines.

Ændringer, du foretager, kan også påvirke de afhængige elementer. Under testen skal du kontrollere, at dine ændringer ikke påvirker eller ødelægger ydeevnen for eksisterende elementer, hvilket kan være afhængigt af de opdaterede elementer.

Du kan nemt finde de relaterede elementer ved hjælp af effektanalyse.

Opdaterer dataelementer

Dataelementer er elementer, der gemmer data. Elementets definition i Git definerer, hvordan dataene gemmes. Når du opdaterer et element i arbejdsområdet, importerer vi dets definition i arbejdsområdet og anvender det på de eksisterende data. Opdateringen af dataelementer er den samme for Git- og udrulningspipelines.

Da forskellige elementer har forskellige funktioner, når det gælder opbevaring af data, når der anvendes ændringer i definitionen, skal du være opmærksom, når du anvender ændringerne. Nogle fremgangsmåder, der kan hjælpe dig med at anvende ændringerne på den sikreste måde:

  • Du skal på forhånd vide, hvad ændringerne er, og hvilken indvirkning de kan have på de eksisterende data. Brug bekræftelsesmeddelelser til at beskrive de ændringer, der er foretaget.

  • Hvis du vil se, hvordan dette element håndterer ændringen med testdata, skal du uploade ændringerne først til et udviklings- eller testmiljø.

  • Hvis alt går godt, anbefales det også at kontrollere det i et midlertidigt miljø med data i det virkelige liv (eller så tæt på det som muligt) for at minimere de uventede funktionsmåder i produktionen.

  • Overvej den bedste timing, når du opdaterer prod-miljøet for at minimere den skade, som eventuelle fejl kan forårsage for de virksomhedsbrugere, der bruger dataene.

  • Efter udrulningen skal du teste efter udrulningen i Prod for at bekræfte, at alt fungerer som forventet.

  • Nogle ændringer vil altid blive betragtet som banebrydende ændringer. Forhåbentlig hjælper de foregående trin dig med at spore dem før produktion. Opret en plan for, hvordan du anvender ændringerne i Prod og gendanner dataene for at vende tilbage til normal tilstand og minimere nedetid for virksomhedsbrugere.

Test din app

Hvis du distribuerer indhold til dine kunder via en app, skal du gennemse appens nye version , før den er i produktion. Da hver udrulningspipelinefase har sit eget arbejdsområde, kan du nemt publicere og opdatere apps til udviklings- og testfaser. Hvis du publicerer og opdaterer apps, kan du teste appen fra slutbrugerens synspunkt.

Vigtigt

Installationsprocessen omfatter ikke opdatering af appindholdet eller -indstillingerne. Hvis du vil anvende ændringer på indhold eller indstillinger, skal du manuelt opdatere appen i den påkrævede pipelinefase.

Produktion

Dette afsnit indeholder en vejledning til produktionsfasen for udrulningspipelines.

Administrer, hvem der kan udrulle til produktion

Da udrulning til produktion skal håndteres omhyggeligt, er det god praksis kun at lade bestemte personer administrere denne følsomme handling. Du vil dog sandsynligvis have, at alle BI-oprettere for et bestemt arbejdsområde skal have adgang til pipelinen. Brug tilladelser til produktionsarbejdsområder til at administrere adgangstilladelser. Andre brugere kan have en visningsrolle for produktionsarbejdsområdet for at få vist indhold i arbejdsområdet, men ikke foretage ændringer fra Git- eller udrulningspipelines.

Derudover skal du begrænse adgangen til lageret eller pipelinen ved kun at aktivere tilladelser til brugere, der er en del af processen til oprettelse af indhold.

Angiv regler for at sikre tilgængeligheden af produktionsfasen

Udrulningsregler er en effektiv måde at sikre, at dataene i produktionen altid er forbundet og tilgængelige for brugerne. Når der er anvendt udrulningsregler, kan udrulninger køre, mens du har sikkerhed for, at kunderne kan se de relevante oplysninger uden forstyrrelser.

Sørg for at angive regler for udrulning af produktion for datakilder og parametre, der er defineret i den semantiske model.

Opdater produktionsappen

Udrulning i en pipeline via brugergrænsefladen opdaterer indholdet i arbejdsområdet. Hvis du vil opdatere den tilknyttede app, skal du bruge API'en til udrulningspipelines. Det er ikke muligt at opdatere appen via brugergrænsefladen. Hvis du bruger en app til distribution af indhold, skal du huske at opdatere appen, når den er udrullet til produktion, så slutbrugerne straks kan bruge den nyeste version.

Udrulning i produktion ved hjælp af Git-forgreninger

Da lageret fungerer som 'enkelt kilde til sandheden', vil nogle teams måske installere opdateringer i forskellige faser direkte fra Git. Dette er muligt med Git-integration med et par overvejelser:

  • Vi anbefaler, at du bruger udgivelsesgrene. Du skal løbende ændre forbindelsen til arbejdsområdet til de nye udgivelsesgrene før hver udrulning.

  • Hvis din build- eller udgivelsespipeline kræver, at du ændrer kildekoden eller kører scripts i et buildmiljø, før du udruller til arbejdsområdet, hjælper det ikke at oprette forbindelse mellem arbejdsområdet og Git.

  • Når du har udrullet til hver fase, skal du sørge for at ændre al konfiguration, der er specifik for den pågældende fase.

Hurtige rettelser til indhold

Nogle gange er der problemer i produktionen, der kræver en hurtig løsning. Det er en dårlig praksis at installere en rettelse uden at teste den først. Implementer derfor altid rettelsen i udviklingsfasen, og send den til resten af faserne i udrulningspipelinen. Udrulning til udviklingsfasen giver dig mulighed for at kontrollere, at rettelsen fungerer, før du udruller den til produktion. Udrulning på tværs af pipelinen tager kun nogle få minutter.

Hvis du bruger udrulning fra Git, anbefaler vi, at du følger de fremgangsmåder, der er beskrevet i Brug en Git-forgreningsstrategi.