Git-integration för utveckling av Fabric-lager

Gäller för: ✅ Warehouse i Microsoft Fabric

Den här artikeln förklarar fördelarna med att utveckla och distribuera Fabric Data Warehouse med Fabric inbyggda Git-integration.

Genom att använda Git-integration i Fabric kan team tillämpa moderna versionshanteringsmetoder vid lagerutveckling. Utvecklare kan isolera förändringar i grenar, följa schemautveckling via commits, samarbeta via pull requests och synkronisera uppdateringar mellan Git-repositorier och Fabric-arbetsytor.

Vanliga scenarier är:

• Att utveckla schemaändringar säkert i grenar och arbetsytor
• Versionshantering av lagerobjekt i Git
• Samarbete över flera filialer och arbetsplatser
• Främjande av validerade förändringar mellan grenar
• Att hålla arbetsytsobjekt (lager och andra) i linje med Git-sanningskällan

För att upprätthålla konsekvens, spårbarhet och tillförlitlighet över lagerutvecklingslivscykler behöver du förstå dessa arbetsflöden.

När du kopplar en Fabric Data Warehouse workspace till Git committar du warehouse-definitioner som ett databasprojekt. Detta projekt blir den auktoritativa representationen av lagerschemat i källkodskontroll och fungerar som grund för pågående utvecklingsaktiviteter. I versionskontrollutforskaren visas schemat som individuella .sql filer.

Genom att använda Fabric Git Integration och Fabric Data Warehouse kan du:

• Utveckla Fabric Data Warehouse med Git-integration.
• Distribuera Fabric Data Warehouse med hjälp av distributionspipelines.
• Distribuera och distribuera kontinuerligt genom att använda Fabric-portalen, Git, din egen IDE eller lokal utvecklingsmiljö, Fabric-distributionspipelines eller externa kontinuerlig integration/kontinuerlig distribution (CI/CD)-system, inklusive pipelines i Azure DevOps Services eller GitHub.

Jämförelse

Under denna synkroniseringsprocess använder Fabric DacFx-baserad inkrementell schemautplacering för att tillämpa ändringar. Denna metod tillämpar endast relevanta schema-skillnader på lagret, istället för att uppdatera hela lagerdefinitionen.

Inkrementell extraktion hjälper till att minska onödig churn i källkontroll, bibehålla renare schema-skillnader mellan grenar och stödja effektiva arbetsflöden för förgrening och sammanslagning. Eftersom extraktionsprocessen är schema-medveten möjliggör den också tillförlitlig jämförelse och validering mellan arbetsytans tillstånd och de Git-spårade definitionerna.

Att standardisera hur lagerscheman extraheras och lagras förbättrar konsekvensen mellan utvecklingsmiljöer. Schemadefinitioner förblir stabila över grenar, skillnader speglar mer exakt avsiktliga utvecklingsförändringar och versionshantering blir en pålitlig baslinje för distribution, samarbete och livscykelhantering.

Själva XMLA.json filen är utesluten under arbetsflödena för Git-integration. Fabric utesluter denna fil från commits och uppdateringar så att standard semantisk model metadata inte oavsiktligt lagras i Git. När man synkroniserar en arbetsyta från Git ignoreras det XMLA.json , vilket hjälper till att undvika konflikter, oavsiktliga överskrivningar och brus under grenväxling eller uppdateringar från Git.

Begränsningar i källkontroll

SQL-säkerhetsfunktioner såsom behörigheter kräver en separat export- och migreringsmetod.

• Tvärbitsberoenden mellan lager och SQL-analysendpoints stöds för närvarande inte i utvecklingsarbetsflöden. Som ett resultat kan scenarier som bygger på samordnade förändringar mellan dessa objekt fungera inte pålitligt.

• Selektiva commits på lagernivå stöds för närvarande inte. Ändringar genomförs på lagerartikelnivå snarare än på mer detaljerade objektnivåer.

• Versionshanteringsstöd för SQL-analysendpoints finns för närvarande inte tillgängligt. Denna begränsning kan begränsa hel livscykelhantering när lösningarna sträcker sig över både lager och SQL-analysändpunkter.

Begränsningar i Git-integrering

• När två eller flera lagerföremål refererar till varandra bildar de ett cykliskt beroende. Systemet upptäcker denna cirkulära referens under branch-out eller Git-till-arbetsområde-synkronisering, vilket gör att dessa operationer misslyckas. Undvik cykliska beroenden mellan föremål.
• Skapa för närvarande inte ett Dataflöde Gen2 med ett utdatamål till lagret. Ett nytt objekt med namnet DataflowsStagingWarehouse visas på lagringsplatsen och blockerar incheckning och uppdatering från Git.
• Beroenden mellan objekt, sekvensering av objekt och synkroniseringsluckor mellan SQL-analysslutpunkten och datavarulagret påverkar "grena ut till en ny eller befintlig arbetsyta" och "växla till en annan gren" under utveckling och kontinuerlig integration.
• Om ett objekt refererar till ett annat objekt i samma lager genom att använda tredelad namngivning (database.schema.object), kan committing eller uppdatering från Git misslyckas. För mer information och en lösning, se Referenser till lagrets egna objekt genom att använda ett tredelat namn.
• Om du ändrar en kolumn som har IDENTITY definierats kan committing eller uppdatering från Git misslyckas tills IDENTITY_INSERT den aktiveras för tabellen.
• Om arkivet innehåller en .sqlproj fil som fäster en äldre Microsoft.Build.Sql SDK-version kan committing eller uppdatering från Git misslyckas eftersom det äldre SDK:t inte känner igen nyare lagersyntax som IDENTITY kolumner och CLUSTER BY. För mer information och en lösning, se Föråldrad .sqlproj i Git-arkivet.
• Om ett objekt refererar till två eller fler tabeller i ett annat lager utan att alias-kvalificera varje kolumn kan committing eller uppdatering från Git misslyckas. För mer information och en lösning, se Icke-kvalificerade kolumner i objekt som refererar till två eller fler tabeller i ett annat lager.
• Om dina skript refererar till två eller flera olika objekt i samma schema i ett annat lager och stavar schemanamnet med inkonsekvent versaler, kan committing eller uppdatering från Git misslyckas. För mer information och en lösning, se Inkonsekvent versalisering av schemanamn.
• Tvetydiga kolumnfel vars kandidatlista innehåller en :: separator kan uppstå vid committing eller uppdatering från Git, även när det inte finns någon verklig tvetydighet. För mer information och lösningar, se Tvetydiga kolumnfel med dubbletter av kandidatobjekt.

Scenarier som inte stöds

Följande CI/CD-arbetsflöden stöds inte officiellt när datalager i olika arbetsytor har olika sorteringsordning. Även om dessa åtgärder kan lyckas utan fel kan de resultera i metadatafel.

I alla dessa scenarier, om ett sorteringskonflikt inträffar, använd Python-skriptet scripts/dw-collation-error-update-tmsl/pbi_interactive.py i Fabric toolbox GitHub-förråd för att uppdatera datamängdens (TMSL) sorteringsordning till att matcha lagersorteringen.

Nästa steg

Relaterat innehåll

• Kom igång med Git-integrering
• Felsök Git-integration för utveckling av Fabric-lager