Zet een warehouse uit met behulp van pipelines

Van toepassing op: ✅ Warehouse in Microsoft Fabric

Microsoft Fabric pijplijnen bieden een gestroomlijnde manier om warehouse-schema's te wijzigen in werkruimtes zoals Dev → Test → Production. Pijplijnen hebben ingebouwde afhankelijkheidsafhandeling, schemavalidatie en declaratieve deployment-intelligentie.

Important

Deze functie is beschikbaar als preview-versie.

Dit artikel legt het proces van magazijnimplementatie met pipelines uit.

Diagram van de pipeline-implementatielevenscyclus voor Fabric Data Warehouse.

Deployment pipelines bieden de levenscyclusstructuur die nodig is om warehousewijzigingen veilig over werkplekken te verplaatsen. Ze fungeren als de centrale orkestratielaag voor schemapromotie, waardoor teams kunnen standaardiseren hoe wijzigingen door het analyseplatform stromen in plaats van te vertrouwen op ad-hoc implementaties. Eenmaal aangemaakt, wordt de pipeline de primaire interface voor het vergelijken van warehouses, het beoordelen van wijzigingen en het uitvoeren van deployments.

Een pijplijn maken

Om een nieuwe pipeline te maken, zie Get Start with deployment pipelines om een deployment pipeline te maken en te beheren.

Compare

Controleer en vergelijk altijd de T-SQL-wijzigingen voordat je ze uitrolt. Deployment pipelines bieden een eenvoudig Vergelijk-scherm in het Fabric-portaal om de getroffen magazijnobjecten te bekijken.

Door de wijzigingen te herzien, kunnen teams de gereedheid valideren voordat updates worden gepromoot naar downstream omgevingen. Dit proces is vooral waardevol in bedrijfsscenario's waar meerdere teams bijdragen aan de ontwikkeling van magazijnen.

Fabric gebruikt DacFx (Data-tier Application Framework) om deze vergelijking uit te voeren. DacFx bouwt een declaratief schemamodel van beide omgevingen en identificeert verschillen zoals nieuwe tabellen, gewijzigde kolommen, beperkingen of afhankelijkheidswijzigingen. Omdat deze vergelijking modelgestuurd is, geeft het nauwkeurig weer wat er tijdens de implementatie gebeurt.

Important

Om schemavergelijking te laten werken, moet het warehouse zowel in de bron- als doelwerkruimtes bestaan. Als de doelwerkruimte het magazijn nog niet bevat, maak of deploy dan eerst een initiële basisversie.

Note

Als de clausule COLLATE van een kolom expliciet dezelfde collatie specificeert als de standaardcollatie van het magazijn, toont de vergelijking dit niet als een verschil, omdat het gelijkstaat aan het helemaal niet specificeren van een collatie. Alleen kolommen waarvan de collatie afwijkt van de standaardcollatie van het magazijn verschijnen in vergelijkingen wanneer hun collatie verandert. Voor meer informatie en een voorbeeld, zie Troubleshoot Git-integratie voor Fabric Data Warehouse ontwikkeling.

Voordat je wijzigingen uitrolt, gebruik je de vergelijkingsfunctie van de deployment pipeline om de verschillen tussen de bron- en doelwarehouse-werkruimtes te bekijken.

Maak een screenshot in het Fabric-portaal met behulp van een pipeline om een magazijn in twee verschillende werkruimtes te vergelijken.

Selecteer Vergelijk en bekijk de wijzigingen, zoals het aanmaken van een nieuwe weergave in het magazijn:

Screenshot van de vergelijking van een magazijn in de ene staat met een magazijn in een andere staat.

Deploy

Nadat de vergelijking is afgerond en je de wijzigingen hebt gevalideerd, kun je direct vanuit de pipeline-interface implementeren door de magazijnartikelen te selecteren die promoot moeten worden.

Screenshot van het Fabric-portaal van de Deploy naar dit stage-scherm in de pipeline.

Tijdens de implementatie gebruiken deployment-pijplijnen DacFx om een intelligent deploymentplan te genereren op basis van schemaverschillen. Fabric past alleen de benodigde wijzigingen toe om de doelwerkruimte synchroon te brengen met de bron.

Screenshot van het Fabric-portaal van een succesvolle implementatie.

Inzetconfiguraties

Fabric deployment-pijplijnen gebruiken DacFx-deploymenttechnologie met configuraties die specifiek zijn afgestemd op Fabric Data Warehouse. Deze configuraties zorgen ervoor dat implementaties betrouwbaar slagen terwijl ze aansluiten bij de mogelijkheden en operationele praktijken van het Fabric-platform.

  • Blokkeren bij mogelijk dataverlies (BlockOnPossibleDataLoss = true) - Fabric Data Warehouse voorkomt uitrolingen die gebruikersgegevens kunnen afkappen, laten vallen of anderszins verliezen. Deze instelling voorkomt dat risicovolle schemawijzigingen door CI/CD glipen en maakt dataverlies een bewuste beslissing in plaats van een stille standaard.

  • Het overslaan van database-niveau optie scripting (ScriptDatabaseOptions = false) - Fabric beheert veel database-niveau instellingen op platformniveau. Scripting statements zoals ALTER DATABASE ... SET tijdens de implementatie kunnen leiden tot storingen of onbedoelde configuratie-afwijking. Deployment pipelines vermijden daarom het verspreiden van deze instellingen, waardoor schema-implementaties zich uitsluitend richten op ondersteunde warehouse-objecten.

  • Engine-handhaving mogelijk maken voor gerepliceerde objecten (DoNotAlterReplicatedObjects = false) - Warehouses gebruiken vaak interne replicatiemechanismen, bijvoorbeeld bij koppel- of synchronisatiescenario's. In plaats van schemawijzigingen voortijdig te blokkeren, stellen deployment-pipelines de Fabric-engine in staat te bepalen of een wijziging is toegestaan. Deze aanpak voorkomt onnodige uitrolfouten terwijl de platformbeveiliging behouden blijft.

  • Transactionele DDL-scripting uitschakelen (IncludeTransactionalScripts = false) - Magazijnen ondersteunen momenteel geen wrapping van DDL-scripts binnen transacties. Deployment-pijplijnen genereren daarom niet-transactionele scripts om te garanderen dat de implementaties succesvol worden afgerond.

  • Gebruik van intelligente standaardinstellingen voor schema-evolutie (GenerateSmartDefaults = true) - Wanneer schemawijzigingen strengere beperkingen introduceren, zoals het omzetten van nullable kolommen naar niet-nullable of het toevoegen van nieuwe kolommen met standaardconstraints, kunnen deployment-pijplijnen automatisch baselinewaarden invullen. Deze aanpak helpt implementaties succesvol te zijn zonder handmatige datavoorbereiding en vermindert operationele wrijving tijdens schema-ontwikkeling.

  • Beveiligingsprincipals uitsluiten uit deployment (ExcludeObjectTypes = Logins, Users, Permissions) - Beveiligingsobjecten worden opzettelijk uitgesloten van warehouse-deployments. Het promoten van logins, gebruikers of permissies tussen omgevingen kan beveiligingsrisico's of omgevingsspecifieke conflicten met zich meebrengen. Beheer in plaats daarvan toegangscontrole apart via omgevingsgovernance of identiteitsbeheerprocessen.

  • Objecten die niet in de bron zitten (DropObjectsNotInSource = false) niet droppen - Objecten die in het doel zitten maar niet in de bron, worden niet automatisch verwijderd. Magazijnen die de productie perfect synchroniseren met de versiebeheer, kunnen dit beperkend vinden.

Limitations

  • Standaard blokkeert het systeem table drops. Het deploymentproces laat niet automatisch objecten vallen die in het doel bestaan, maar niet in de bron. Dit ontwerp vermindert accidenteel dataverlies en voorkomt onverwachte verwijderingen in de productie.
  • Een succesvolle implementatie betekent niet altijd dat elke gevraagde wijziging is toegepast. Een deployment kan succes rapporteren zelfs wanneer een gevraagde droptable-actie wordt overgeslagen, omdat table drops standaard worden geblokkeerd. In dat geval wordt de deployment-operatie voltooid, maar het doelwit kan nog steeds van de source control afwijken totdat je de ontbrekende wijziging expliciet hebt opgelost.
  • Fabric Implementatiepijplijnen bieden geen ondersteuning voor het eindpuntitem van SQL Analytics. Momenteel geeft het implementatieproces prioriteit aan veiligheid boven strikte bronpariteit door objecten die alleen in het doel bestaan niet te laten vallen.
  • Afhankelijkheden tussen items, itemvolgorde en synchronisatieverschillen tussen het SQL-analyse-eindpunt en het datawarehouse beïnvloeden de werkstromen van Fabric-implementatiepijplijnen.
  • Met Fabric Deployment-pijplijnen kun je slechts één warehouse tegelijk uitzetten. Het selecteren van gerelateerde items voor deployment wordt niet ondersteund.

Problemen met Git-integratie oplossen

Voor beperkingen specifiek voor Git-integratie, zie Beperkingen in Git-integratie in het Git-integratieartikel.

Voor probleemoplossing, workarounds en oplossingen voor veelvoorkomende Git-integratieproblemen in Fabric Data Warehouse ontwikkeling, zie Troubleshoot Git integration voor Fabric Data Warehouse ontwikkeling.

Verwante onderwerpen

  • Last updated on