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:

  • Veilig schemawijzigingen ontwikkelen in branches en werkruimtes
  • Versiebeheer van warehouse-objecten in Git
  • Samenwerken over meerdere vestigingen en werkruimtes
  • Het bevorderen van gevalideerde veranderingen tussen vestigingen
  • Items in de werkruimte (Warehouse en andere) afgestemd houden op de bron van waarheid in Git

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-werkruimte verbindt met Git, leg je de definities van het datawarehouse vast 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. Wanneer een werkruimte met Git wordt gesynchroniseerd, wordt XMLA.json genegeerd, wat helpt conflicten, onbedoelde overschrijvingen en ruis te voorkomen tijdens het wisselen van branch of updates vanuit Git.

Beperkingen in broncodebeheer

  • SQL-beveiligingsfuncties zoals permissies vereisen een scriptgebaseerde aanpak voor export en migratie. Overweeg het gebruik van een script na de implementatie in een SQL-databaseproject. Je kunt een script na de uitrol in het project configureren met de SQL Database Projects-extensie die beschikbaar is in Visual Studio Code.

  • 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.

  • Pre-deployment of post-deployment scripts en extra publicatieconfiguraties die direct via Git aan het databaseproject worden toegevoegd, worden niet bewaard als onderdeel van de ontwikkelworkflows. Je moet deze configuraties misschien apart beheren buiten de Fabric-werkruimte.

  • Selectieve boekingen 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 met behulp van driedelige naamgeving (database.schema.object) naar een ander object in hetzelfde datawarehouse verwijst, kan het vastleggen of bijwerken vanuit Git mislukken. Voor meer informatie en een workaround, zie Verwijzingen naar de eigen objecten van het magazijn met een driedelige naam.
  • Als je een kolom wijzigt waarvoor IDENTITY is gedefinieerd, kan het committen of bijwerken vanuit Git mislukken totdat IDENTITY_INSERT is ingeschakeld voor de tabel.
  • 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 verwijzen naar twee of meer verschillende objecten in hetzelfde schema van een ander warehouse en de schemanaam niet consequent met hoofdletters schrijven, kan committen of updaten via Git mislukken. 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 tijdelijke oplossingen, raadpleeg 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