Git-integrasjon for utvikling av Fabric-lageret

Gjelder for: ✅ Warehouse i Microsoft Fabric

Denne artikkelen forklarer fordelene ved å utvikle og distribuere Fabric datalager med Fabric sin innebygde Git-integrasjon.

Ved å bruke Git-integrasjon i Fabric kan team anvende moderne kildekontrollpraksis på lagerutvikling. Utviklere kan isolere endringer i greiner, spore skjemautvikling gjennom commits, samarbeide gjennom pull requests, og synkronisere oppdateringer mellom Git-repositorier og Fabric-arbeidsområder.

Vanlige scenarioer omfatter:

• Utvikling av skjemaendringer trygt i grener og arbeidsområder
• Versjonering av varehusobjekter i Git
• Samarbeid på tvers av flere avdelinger og arbeidsområder
• Fremme validerte endringer mellom grener
• Å holde arbeidsplass-elementer (lager og andre) i tråd med Git-kilden til sannheten

For å opprettholde konsistens, sporbarhet og pålitelighet gjennom lagerutviklingslivssykluser, må du forstå disse arbeidsflytene.

Når du kobler et Fabric datalager arbeidsområde til Git, committer du warehouse-definisjoner som et databaseprosjekt. Dette prosjektet blir den autoritative representasjonen av lagerskjemaet i kildekontroll og fungerer som grunnlaget for pågående utviklingsaktiviteter. I kildekontrollutforskeren vises skjemaet som individuelle .sql filer.

Ved å bruke Fabric Git-integrasjon og Fabric datalager kan du:

• Utvikle Fabric datalager med Git-integrasjon.
• Distribuer Fabric datalager ved å bruke distribusjonspipelines.
• Distribuer og distribuer kontinuerlig ved å bruke Fabric-portalen, Git, din egen IDE eller lokale utviklingsmiljø, Fabric-distribusjonspipelines, eller eksterne kontinuerlig integrasjon/kontinuerlig distribusjon (CI/CD)-systemer, inkludert pipelines i Azure DevOps Services eller GitHub.

Sammenligning

Under denne synkroniseringsprosessen bruker Fabric DacFx-basert inkrementell skjemadistribusjon for å anvende endringer. Denne tilnærmingen anvender kun de relevante skjemaforskjellene på lageret, i stedet for å oppdatere hele lagerdefinisjonen.

Inkrementell ekstraksjon bidrar til å redusere unødvendig churm i kildekontroll, opprettholde renere skjemaforskjeller mellom grener, og støtte effektive forgrenings- og sammenslåingsarbeidsflyter. Siden utvinningsprosessen er skjemabevisst, muliggjør den også pålitelig sammenligning og validering mellom arbeidsområdets tilstand og de Git-sporede definisjonene.

Standardisering av hvordan lagerskjemaer hentes ut og lagres forbedrer konsistensen på tvers av utviklingsmiljøer. Skjemadefinisjoner forblir stabile på tvers av grener, forskjeller gjenspeiler mer nøyaktig bevisste utviklingsendringer, og kildekodekontroll blir et pålitelig utgangspunkt for distribusjon, samarbeid og livssyklusstyring.

Selve XMLA.json filen er ekskludert under Git-integrasjonsarbeidsflytene. Fabric ekskluderer denne filen fra commits og oppdateringer, slik at standard semantisk model metadata ikke utilsiktet lagres i Git. Når man synkroniserer et arbeidsområde fra Git, XMLA.json ignoreres det, noe som hjelper å unngå konflikter, utilsiktede overskrivinger og støy under grenbytte eller oppdateringer fra Git.

Begrensninger i kildekontroll

SQL-sikkerhetsfunksjoner som tillatelser krever en separat eksport- og migreringsmetode.

• Tverrproduktavhengigheter mellom lagre og SQL-analyseendepunkter støttes for øyeblikket ikke i utviklingsarbeidsflyter. Som et resultat kan scenarier som er avhengige av koordinerte endringer på tvers av disse elementene fungere dårlig.

• Selektive commits på lagernivå støttes ikke for øyeblikket. Endringer utføres på lagervarenivå i stedet for på mer detaljerte objektnivåer.

• Versjonskontrollstøtte for SQL-analyseendepunkter er for øyeblikket ikke tilgjengelig. Denne begrensningen kan begrense ende-til-ende livssyklusstyring når løsningene dekker både lagre og SQL-analyseendepunkter.

Begrensninger i Git-integrering

• Når to eller flere lagerartikler refererer til hverandre, danner de en syklisk avhengighet. Systemet oppdager denne sirkulære referansen under branch-out eller Git-til-arbeidsområde-synkronisering, noe som fører til at disse operasjonene feiler. Unngå sykliske avhengigheter mellom elementer.
• For øyeblikket, ikke lag en Dataflow Gen2 med en utgangsdestinasjon til lageret. Et nytt element med navn DataflowsStagingWarehouse dukker opp i repositoriet og blokkerer committing og oppdatering fra Git.
• Tverrpunktavhengigheter, varesekvensering og synkroniseringshull mellom SQL-analyseendepunktet og lageret påvirker arbeidsflytene for «å forgrene seg til et nytt eller eksisterende arbeidsområde» og «bytte til en annen gren» under utvikling og kontinuerlig integrasjon.
• Hvis et objekt refererer til et annet objekt i samme lager ved å bruke tre-delt navngivning (database.schema.object), kan committing eller oppdatering fra Git feile. For mer informasjon og en løsning, se Referanser til lagerets egne objekter ved å bruke et tredelt navn.
• Hvis du endrer en kolonne som har IDENTITY definert, kan committing eller oppdatering fra Git feile inntil IDENTITY_INSERT den er aktivert for tabellen.
• Hvis repositoriet inneholder en .sqlproj fil som fester en eldre Microsoft.Build.Sql SDK-versjon, kan committing eller oppdatering fra Git feile fordi den eldre SDK-en ikke gjenkjenner nyere lagersyntaks som IDENTITY kolonner og CLUSTER BY. For mer informasjon og en løsning, se Utdatert .sqlproj i Git-repositoriet.
• Hvis et objekt refererer til to eller flere tabeller i et annet lager uten å alias-kvalifisere hver kolonne, kan committing eller oppdatering fra Git feile. For mer informasjon og en løsning, se Ukvalifiserte kolonner i objekter som refererer til to eller flere tabeller i et annet lager.
• Hvis skriptene dine refererer til to eller flere forskjellige objekter i samme skjema i et annet lager og staver skjemanavnet med inkonsekvent store bokstaver, kan committing eller oppdatering fra Git feile. For mer informasjon og en løsning, se Inkonsistent store bokstaver i skjemanavn.
• Tvetydige kolonnefeil hvis kandidatliste inneholder en :: separator kan oppstå ved committing eller oppdatering fra Git, selv når det ikke er noen reell tvetydighet. For mer informasjon og løsninger, se Tvetydige kolonnefeil med dupliserte kandidatobjekter.

Scenarier som ikke støttes

Følgende CI/CD-arbeidsflyter støttes ikke offisielt når lagre i forskjellige arbeidsområder har ulike sorteringer. Selv om disse operasjonene kan lykkes uten feil, kan de føre til metadatafeil.

I alle disse situasjonene, hvis det oppstår en kollasjonsmismatch, bruk Python-skriptet scripts/dw-collation-error-update-tmsl/pbi_interactive.py i Fabric toolbox GitHub-repositoriet for å oppdatere datasettets (TMSL)-kollasjon slik at den matcher warehouse-sorteringen.

Neste trinn:

Relatert innhold

• Kom i gang med Git-integrasjon
• Feilsøk Git-integrasjon for utvikling av Fabric-lageret