Git-integratie voor de ontwikkeling van Fabric warehouse

Van toepassing op: ✅ Warehouse in Microsoft Fabric

Dit artikel legt de voordelen uit van het ontwikkelen en uitrollen van Fabric Data Warehouse met de ingebouwde Git-integratie van Fabric.

Important

Deze functie is beschikbaar als preview-versie.

Door gebruik te maken van Git-integratie in Fabric kunnen teams moderne versiebeheerpraktijken toepassen op warehouse-ontwikkeling. Ontwikkelaars kunnen wijzigingen in branches isoleren, schema-evolutie volgen via commits, samenwerken via pull requests en updates synchroniseren tussen Git-repositories en Fabric-werkruimtes.

Enkele gangbare scenario's zijn:

  • Schemawijzigingen veilig ontwikkelen in branchs en werkruimtes
  • Versiebeheer van warehouse-objecten in Git
  • Samenwerken over meerdere vestigingen en werkruimtes
  • Het bevorderen van gevalideerde veranderingen tussen vestigingen
  • Workspace-items (magazijn en andere) in lijn houden met de Git-bron van waarheid

Om consistentie, traceerbaarheid en betrouwbaarheid te behouden over de hele levenscycli van magazijnontwikkeling, moet je deze workflows begrijpen.

Diagram van de ontwikkelingscyclus van de Fabric Warehouse Git-integratie.

Wanneer je een Fabric Data Warehouse workspace verbindt met Git, commi je warehouse-definities als een databaseproject. Dit project wordt de gezaghebbende representatie van het warehouse-schema in source control en dient als basis voor lopende ontwikkelingsactiviteiten. In de source control explorer verschijnt het schema als afzonderlijke .sql bestanden.

Screenshot van het schema van een warehouse in de source control explorer.

Door gebruik te maken van Fabric Git Integration en Fabric Data Warehouse kunt u:

Comparison

Tijdens dit synchronisatieproces gebruikt Fabric DacFx-gebaseerde incrementele schema-implementatie om wijzigingen toe te passen. Deze aanpak past alleen de relevante schemaverschillen toe op het magazijn, in plaats van de volledige magazijndefinitie bij te werken.

Incrementele extractie helpt onnodige churn in source control te verminderen, zorgt voor nettere schemaverschillen tussen branches en ondersteunt efficiënte branching- en mergingworkflows. Omdat het extractieproces schema-bewust is, maakt het ook betrouwbare vergelijking en validatie mogelijk tussen de werkruimtestatus en de door Git gevolgde definities.

Het standaardiseren van hoe warehouse-schema's worden uitgehing en opgeslagen verbetert de consistentie tussen ontwikkelomgevingen. Schemadefinities blijven stabiel over branches heen, verschillen weerspiegelen intentionele ontwikkelingswijzigingen nauwkeuriger, en source control wordt een betrouwbare basis voor deployment, samenwerking en lifecycle management.

Het XMLA.json bestand zelf wordt uitgesloten tijdens de Git-integratieworkflows. Fabric sluit dit bestand uit van commits en updates, zodat de standaard semantische model metadata niet per ongeluk in Git wordt opgeslagen. Bij het synchroniseren van een werkruimte vanuit Git wordt genegeerd, XMLA.json wat helpt conflicten, onbedoelde overschrijvingen en ruis tijdens branchswitching of updates vanuit Git te voorkomen.

Beperkingen in broncodebeheer

SQL-beveiligingsfuncties zoals permissies vereisen een aparte export- en migratiemethode.

  • Cross-item-afhankelijkheden tussen magazijnen en SQL-analyse-eindpunten worden momenteel niet ondersteund in ontwikkelingsworkflows. Daardoor werken scenario's die afhankelijk zijn van gecoördineerde veranderingen over deze items mogelijk niet betrouwbaar.

  • Selectieve commits op magazijnniveau worden momenteel niet ondersteund. Wijzigingen worden op het niveau van het magazijnitem uitgevoerd in plaats van op fijnere objectniveaus.

  • Versiebeheerondersteuning voor SQL-analyse-endpoints is momenteel niet beschikbaar. Deze beperking kan end-to-end levenscyclusbeheer beperken wanneer oplossingen zowel warehouses als SQL-analytics-endpoints beslaan.

Beperkingen in Git-integratie

  • Wanneer twee of meer magazijnartikelen elkaar verwijzen, vormen ze een cyclische afhankelijkheid. Het systeem detecteert deze circulaire verwijzing tijdens branch-out of Git-naar-werkruimte synchronisatiebewerkingen, waardoor deze bewerkingen falen. Vermijd cyclische afhankelijkheden tussen items.
  • Maak op dit moment geen Dataflow Gen2 met een uitvoerbestemming naar het datamagazijn. Er verschijnt een nieuw item met de naam DataflowsStagingWarehouse in de opslagplaats, waardoor het doorvoeren en bijwerken vanuit Git wordt geblokkeerd.
  • Afhankelijkheden tussen items, itemvolgordebepaling en synchronisatieverschillen tussen het SQL Analytics-eindpunt en het datamagazijn hebben invloed op de werkstromen 'branching naar een nieuwe of bestaande werkruimte' en 'overschakelen naar een andere branch' tijdens de ontwikkeling en continue integratie.
  • Als een object een ander object in hetzelfde warehouse verwijst via drieledige naamgeving (database.schema.object), kan committen of updaten vanuit Git falen. Voor meer informatie en een workaround, zie Verwijzingen naar de eigen objecten van het magazijn met een driedelige naam.
  • Als je een kolom verandert die gedefinieerd is IDENTITY , kan committen of updaten vanuit Git falen totdat IDENTITY_INSERT deze voor de tabel is ingeschakeld.
  • Als de repository een .sqlproj bestand bevat dat een oudere Microsoft.Build.Sql SDK-versie vastpint, kan committen of updaten vanuit Git falen omdat de oudere SDK nieuwere warehouse-syntaxis zoals IDENTITY kolommen en CLUSTER BYniet herkent. Voor meer informatie en een workaround, zie verouderde .sqlproj in de Git-repository.
  • Als een object twee of meer tabellen in een ander warehouse verwijst zonder elke kolom te alias-kwalificeren, kan commit of updaten vanuit Git falen. Voor meer informatie en een workaround, zie Ongekwalificeerde kolommen in objecten die verwijzen naar twee of meer tabellen in een ander magazijn.
  • Als je scripts twee of meer verschillende objecten in hetzelfde schema van een ander warehouse refereren en de schemanaam spellen met inconsistente hoofdlettergebruik, kan committen of updaten vanuit Git falen. Voor meer informatie en een workaround, zie Inconsistente hoofdlettergebruik van schemanamen.
  • Dubbelzinnige kolomfouten waarvan de kandidatenlijst een :: scheider bevat, kunnen optreden bij committen of updaten vanuit Git, zelfs als er geen echte ambiguïteit is. Voor meer informatie en workarounds, zie Ambiguous column errors with duplicate candidate objects.

Niet ondersteunde scenario's

De volgende CI/CD-werkstromen worden niet officieel ondersteund wanneer magazijnen in verschillende werkruimten verschillende sorteringen hebben. Hoewel deze bewerkingen zonder fouten kunnen slagen, kunnen ze leiden tot metagegevensfouten.

Als in al deze scenario's een sortering niet overeenkomt, gebruikt u het Python script scripts/dw-collation-error-update-tmsl/pbi_interactive.py in de Fabric toolbox GitHub repository om de sortering van de dataset (TMSL) bij te werken zodat deze overeenkomt met de sortering van het magazijn.

Scenario Beschrijving Risico
Implementatiepijplijnen Het promoten van magazijninhoud via pijplijnfasen (bijvoorbeeld Dev → Test → Prod) waarbij het doelwarehouse is gemaakt met een andere sortering dan de bron wordt niet ondersteund. De implementatie kan slagen, maar de sortering van de gegevensset wordt niet bijgewerkt zodat deze overeenkomt met de sortering van het doelwarehouse.
Vertakking naar een nieuwe of bestaande werkruimte Het gebruik van Git-integratie om vanuit een bestaande werkruimte te vertakken naar een nieuwe of bestaande werkruimte waar het magazijn een andere sortering heeft, wordt niet ondersteund. Warehouse-inhoud wordt gesynchroniseerd, maar de sorteringsmetagegevens worden niet afgestemd.
Branches wisselen in een werkruimte Overschakelen naar een branch die is gekoppeld aan een magazijn met een andere sorteringsvolgorde in een met Git verbonden werkruimte wordt niet ondersteund. Gesynchroniseerde inhoud kan sorteringsveronderstellingen bevatten die niet overeenkomen met het huidige magazijn.
Wijzigingen tussen werkruimten samenvoegen via branches Het samenvoegen van Git-vertakkingen in werkruimten waarin de magazijnen verschillende sorteringen hebben, wordt niet ondersteund. Samenvoegen kan op Git-niveau worden uitgevoerd, maar de resulterende sortering van de gegevensset komt niet overeen met de sortering van het doelwarehouse.

Volgende stap

Gebruik Git Integration voor magazijnontwikkeling en -implementatie

Verwante onderwerpen

  • Last updated on