Git-integration til udvikling af Fabric-lagerbygninger

Gælder for: ✅ Lager i Microsoft Fabric

Denne artikel forklarer fordelene ved at udvikle og implementere Fabric data warehouse med Fabric's indbyggede Git-integration.

Vigtigt!

Denne funktion er en prøveversion.

Ved at bruge Git-integration i Fabric kan teams anvende moderne versionskontrolpraksis på lagerudvikling. Udviklere kan isolere ændringer i branches, følge skemaudvikling gennem commits, samarbejde gennem pull requests og synkronisere opdateringer mellem Git-repositories og Fabric-arbejdsområder.

Typiske scenarier omfatter:

  • Udvikling af skemaændringer sikkert i grene og arbejdsområder
  • Versionsstyring af warehouse-objekter i Git
  • Samarbejde på tværs af flere afdelinger og arbejdspladser
  • Fremme validerede ændringer mellem grene
  • At holde arbejdsområdeelementer (lager og andre) i overensstemmelse med Git-kilden til sandheden

For at opretholde konsistens, sporbarhed og pålidelighed gennem lagerudviklingslivscyklusser skal du forstå disse arbejdsgange.

Diagram over Fabric Warehouse Git-integrations udviklingslivscyklus.

Når du forbinder et Fabric data warehouse workspace til Git, committer du warehouse-definitioner som et databaseprojekt. Dette projekt bliver den autoritative repræsentation af lagerskemaet i kildekontrol og fungerer som fundament for løbende udviklingsaktiviteter. I versionsfinderfilen vises skemaet som individuelle .sql filer.

Skærmbillede af skemaet for et lager i versionsfinder.

Ved at bruge Fabric Git Integration og Fabric data warehouse kan du:

Sammenligning

Under denne synkroniseringsproces bruger Fabric DacFx-baseret inkrementel skema-udrulning til at anvende ændringer. Denne tilgang anvender kun de relevante skemaforskelle på lageret i stedet for at opdatere hele lagerdefinitionen.

Inkrementel udtrækning hjælper med at reducere unødvendig churn i versionskontrol, opretholde renere skemaforskelle på tværs af grene og understøtte effektive forgrenings- og sammenflettningsarbejdsgange. Da udtrækningsprocessen er skema-bevidst, muliggør den også pålidelig sammenligning og validering mellem arbejdsområdets tilstand og de Git-trackede definitioner.

Standardisering af, hvordan lagerskemaer udtrækkes og lagres, forbedrer konsistensen på tværs af udviklingsmiljøer. Skemadefinitioner forbliver stabile på tværs af branches, forskelle afspejler mere præcist intentionelle udviklingsændringer, og versionskontrol bliver et pålideligt udgangspunkt for deployment, samarbejde og livscyklusstyring.

Selve XMLA.json filen udelukkes under Git-integrationsworkflows. Fabric udelukker denne fil fra commits og opdateringer, så standard semantisk model metadata ikke utilsigtet gemmes i Git. Når man synkroniserer et arbejdsområde fra Git, ignoreres det XMLA.json , hvilket hjælper med at undgå konflikter, utilsigtede overskrivninger og støj under branch switching eller opdateringer fra Git.

Begrænsninger i kildestyring

SQL-sikkerhedsfunktioner som tilladelser kræver en separat eksport- og migrationstilgang.

  • Tvær-punkt-afhængigheder mellem lagre og SQL-analyse-endpoints understøttes ikke i udviklingsworkflows i øjeblikket. Som følge heraf kan scenarier, der afhænger af koordinerede ændringer på tværs af disse elementer, muligvis ikke fungere pålideligt.

  • Selektive commits på lagerniveau understøttes ikke i øjeblikket. Ændringer udføres på lagervareniveau i stedet for på finere objektniveau.

  • Versionskontrolunderstøttelse for SQL-analyse-endpoints er ikke tilgængelig i øjeblikket. Denne begrænsning kan begrænse end-to-end livscyklusstyring, når løsninger spænder over både lagre og SQL-analyseendepunkter.

Begrænsninger i Git-integration

  • Når to eller flere lagervarer refererer til hinanden, danner de en cyklisk afhængighed. Systemet registrerer denne cirkulære reference under branch-out eller Git-til-arbejdsområde synkroniseringsoperationer, hvilket får disse operationer til at fejle. Undgå cykliske afhængigheder mellem genstande.
  • Lige nu bør du ikke oprette en Dataflow Gen2 med en outputdestination til lageret. Et nyt element med navn DataflowsStagingWarehouse dukker op i repositoryet og blokerer committing og opdatering fra Git.
  • Tværpunktsafhængigheder, varesekvensering og synkroniseringshuller mellem SQL-analyse-endpointet og lageret påvirker "at forgrene sig til et nyt eller eksisterende arbejdsområde" og "skifte til en anden gren" arbejdsgange under udvikling og kontinuerlig integration.
  • Hvis et objekt refererer til et andet objekt i samme lager ved at bruge tre-delt navngivning (database.schema.object), kan committing eller opdatering fra Git fejle. For mere information og en løsning, se Referencer til lagerets egne objekter ved at bruge et tredelt navn.
  • Hvis du ændrer en kolonne, der har IDENTITY defineret, kan committing eller opdatering fra Git fejle, indtil IDENTITY_INSERT den er aktiveret for tabellen.
  • Hvis repositoryet indeholder en .sqlproj fil, der pin-pinner en ældre Microsoft.Build.Sql SDK-version, kan committing eller opdatering fra Git fejle, fordi det ældre SDK ikke genkender nyere warehouse-syntaks som IDENTITY kolonner og CLUSTER BY. For mere information og en løsning, se Forældet .sqlproj i Git-repositoriet.
  • Hvis et objekt refererer til to eller flere tabeller i et andet lager uden at alias-kvalificere hver kolonne, kan committing eller opdatering fra Git fejle. For mere information og en løsning, se Ukvalificerede kolonner i objekter, der refererer til to eller flere tabeller i et andet lager.
  • Hvis dine scripts refererer til to eller flere forskellige objekter i det samme skema i et andet lager og staver skemanavnet med inkonsekvent store bogstaver, kan committing eller opdatering fra Git fejle. For mere information og en løsning, se Inkonsekvent brug af store bogstaver i skemanavne.
  • Tvetydige kolonnefejl, hvis kandidatliste indeholder en :: separator, kan opstå ved committing eller opdatering fra Git, selv når der ikke er nogen reel tvetydighed. For mere information og løsninger, se Tvetydige kolonnefejl med duplikerede kandidatobjekter.

Ikke-understøttede scenarier

Følgende CI/CD-arbejdsgange understøttes ikke officielt, når lagre i forskellige arbejdsområder har forskellige kollationer. Selvom disse operationer måske lykkes uden fejl, kan de resultere i metadatafejl.

I alle disse scenarier, hvis der opstår en sammenligning i sammenligningen, skal Python-scriptet scripts/dw-collation-error-update-tmsl/pbi_interactive.py i Fabric toolbox GitHub-repositoriet til at opdatere datasættet (TMSL)-kollationen, så den matcher lagerets kollation.

Scenarie Description Risiko
Udrulningspipelines Promovering af warehouse-indhold gennem pipeline-faser (for eksempel Dev → Test → Prod), hvor mål-warehouset blev oprettet med en anden sammenstilling end kildekoden, understøttes ikke. Implementering kan lykkes, men datasættets samling opdateres ikke til at matche mållagerets samling.
Udvidelse til et nyt eller eksisterende arbejdsområde At bruge Git-integration til at udvide fra et eksisterende arbejdsområde til et nyt eller eksisterende arbejdsområde, hvor lageret har en anden sortering, understøttes ikke. Warehouse-indholdet synkroniseres, men samlingsmetadataene bliver ikke afstemt.
Skiftegrene på et arbejdsområde At skifte til en gren, der var tilknyttet et lager af en anden sammenstilling på et Git-forbundet arbejdsområde, understøttes ikke. Synkroniseret indhold kan overføre samlingsantagelser, der ikke matcher det nuværende lager.
Sammenfletting af ændringer mellem arbejdsområder gennem grene At sammenflette Git-grene på tværs af arbejdsområder, hvor lagrene har forskellige kollations, understøttes ikke. Merge kan lykkes på Git-niveau, men den resulterende datasæt-samling afspejler ikke mållagerets samling.

Næste trin

Brug Git Integration til udvikling og implementering af lagere

Relateret indhold

  • Last updated on