Distribuera ett lager med hjälp av pipelines

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

Microsoft Fabric pipelines erbjuder ett smidigt sätt att ändra lagerscheman över arbetsytor som Dev → Test → Production. Pipelines har inbyggd beroendehantering, schemavalidering och deklarativ distributionsintelligens.

Important

Den här funktionen är i förhandsversion.

Den här artikeln förklarar processen för lagerdistribution med pipelines.

Diagram över pipeline-utrullningslivscykeln för Fabric Data Warehouse.

Distributionspipelines tillhandahåller den livscykelstruktur som behövs för att flytta lagerändringar säkert mellan arbetsplatser. De fungerar som det centrala orkestreringslagret för schema-marknadsföring, vilket gör det möjligt för team att standardisera hur förändringar flyter genom analysplattformen istället för att förlita sig på ad hoc-distributioner. När pipelinen väl är skapad blir den primära gränssnittet för att jämföra lager, granska ändringar och genomföra distributioner.

Skapa en pipeline

För att skapa en ny pipeline, se Get Started with deployment pipelines för att skapa och hantera en distributionspipeline.

Jämför

Verifiera och jämför alltid T-SQL-ändringarna innan du implementerar dem. Distributionspipelines erbjuder en enkel Jämför-skärm i Fabric-portalen för att granska de berörda lagerobjekten.

Att granska förändringarna gör det möjligt för team att validera beredskap innan uppdateringar marknadsförs till nedströmsmiljöer. Denna process är särskilt värdefull i företagsscenarier där flera team bidrar till lagerutveckling.

Fabric använder DacFx (Data-tier Application Framework) för att utföra denna jämförelse. DacFx bygger en deklarativ schemamodell av båda miljöerna och identifierar skillnader såsom nya tabeller, modifierade kolumner, begränsningar eller beroendeförändringar. Eftersom denna jämförelse är modelldriven speglar den korrekt vad som händer under driftsättningen.

Important

För att schemajämförelse ska fungera måste lagret finnas i både käll- och målarbetsytorna. Om målarbetsytan ännu inte innehåller lagret, skapa eller distribuera en initial baslinjeversion först.

Note

Om en kolumns COLLATE klausul uttryckligen anger samma sortering som lagrets standardsortering, visar jämförelsen det inte som en skillnad, eftersom det är likvärdigt med att inte specificera en sortering alls. Endast kolumner vars sortering skiljer sig från lagerets standardsortering visas i jämförelser när deras sortering ändras. För mer information och ett exempel, se Felsök Git-integration för Fabric Data Warehouse utveckling.

Innan du distribuerar några ändringar, använd distributionspipelinens jämförelsefunktion för att granska skillnader mellan käll- och mållagerets arbetsytor.

Ta en skärmdump i Fabric-portalen med en pipeline för att jämföra ett lager i två olika arbetsytor.

Välj Jämför och visa ändringarna, till exempel att skapa en ny vy i lagret:

Skärmdump av jämförelsen mellan ett lager i en delstat och ett lager i en annan.

Deploy

När jämförelsen är klar och du validerar ändringarna kan du distribuera direkt från pipelinegränssnittet genom att välja lagerföremålen att marknadsföra.

Skärmdump från Fabric-portalen för Deploy till denna stegskärm i pipelinen.

Under distribution använder distributionspipelines DacFx för att generera en intelligent distributionsplan baserad på schema-skillnader. Fabric tillämpar endast de nödvändiga ändringarna för att få målarbetsytan synkroniserad med källkoden.

Skärmdump från Fabric-portalen av en lyckad utplacering.

Utplaceringskonfigurationer

Fabric distributionspipelines använder DacFx-distributionsteknologi med konfigurationer anpassade specifikt för Fabric Data Warehouse. Dessa konfigurationer säkerställer att driftsättningar lyckas pålitligt samtidigt som de är anpassade till Fabric-plattformens kapacitet och operativa rutiner.

  • Blockering vid möjlig dataförlust (BlockOnPossibleDataLoss = true) - Fabric Data Warehouse förhindrar utplaceringar som kan förkorta, förlora eller på annat sätt förlora användardata. Denna inställning hindrar att högriskändringar i schemat glider igenom CI/CD och gör risken för dataförlust till ett medvetet beslut istället för en tyst standard.

  • Hoppa över databasnivå-optionskriptning (ScriptDatabaseOptions = false) - Fabric hanterar många databasnivåinställningar på plattformsnivå. Skriptsatser, såsom ALTER DATABASE ... SET under utrullning, kan leda till fel eller oavsiktlig konfigurationsdrift. Distributionspipelines undviker därför att sprida dessa inställningar och säkerställer att schema-distributioner endast fokuserar på stödda lagerobjekt.

  • Tillåtande av motorkontroll för replikerade objekt (DoNotAlterReplicatedObjects = false) – Lager använder ofta interna replikeringsmekanismer, till exempel i länknings- eller synkroniseringsscenarier. Istället för att blockera schemaändringar i förtid, tillåter deploymentspipelines Fabric-motorn att avgöra om en ändring är tillåten. Denna metod förhindrar onödiga distributionsfel samtidigt som plattformens skydd bevaras.

  • Inaktivera transaktionell DDL-skriptning (IncludeTransactionalScripts = false) - Lager stöder för närvarande inte wrapping av DDL-skript i transaktioner. Distributionspipelines genererar därför icke-transaktionella skript för att säkerställa att distributioner slutförs framgångsrikt.

  • Användning av intelligenta standardinställningar för schemautveckling (GenerateSmartDefaults = true) - När schemaändringar introducerar striktare begränsningar, såsom att omvandla nullbara kolumner till icke-nullbara eller lägga till nya kolumner med standardbegränsningar, kan distributionspipelines automatiskt fylla i baslinjevärden. Denna metod hjälper implementeringar att lyckas utan att kräva manuell dataförberedelse och minskar operativ friktion under schemautveckling.

  • Exkludering av säkerhetsprinciper från distribution (ExcludeObjectTypes = Logins, Users, Permissions) - Säkerhetsobjekt utesluts medvetet från lagerdistributioner. Att främja inloggningar, användare eller behörigheter över miljöer kan innebära säkerhetsrisker eller miljöspecifika konflikter. Hantera istället åtkomstkontroll separat genom miljöstyrning eller identitetshantering.

  • Att inte släppa objekt som inte finns i källkoden (DropObjectsNotInSource = false) - Objekt som finns i målet men inte i källkoden tas inte automatiskt bort. Lager som håller produktionen helt synkroniserad med versionskontrollen kan uppleva detta som begränsande.

Limitations

  • Som standard blockerar systemet tabelldroppar. Distributionsprocessen släpper inte automatiskt objekt som finns i målet men inte i källkoden. Denna design minskar oavsiktlig dataförlust och förhindrar oväntade borttagningar i produktionen.
  • En lyckad distribution betyder inte alltid att varje begärd ändring har gjorts. En distribution kan rapportera framgång även när den hoppar över en begärd drop-table-åtgärd, eftersom tabelldroppar blockeras som standard. I så fall slutförs distributionsoperationen, men målet kan fortfarande driva från versionskontrollen tills du uttryckligen löser den saknade ändringen.
  • Fabric Distributionspipelines stöder inte SQL-analysslutpunktsobjektet. För närvarande prioriterar distributionsprocessen säkerhet framför strikt källkodsparitet genom att inte släppa objekt som endast finns i målet.
  • Beroenden mellan objekt, objektsekvensering och synkroniseringsluckor mellan SQL-analysslutpunkten och datavarehuset påverkar arbetsflöden för Fabric Deployment Pipelines.
  • Med Fabric Deployment-pipelines kan du bara distribuera ett lager åt gången. Att välja relaterade objekt för utrullning stöds inte.

Felsökning av Git-integration

För begränsningar specifika för Git-integration, se Begränsningar i Git-integration i artikeln om Git-integration.

För felsökning, lösningar och lösningar på vanliga Git-integrationsproblem i Fabric Data Warehouse utveckling, se Felsökning av Git-integration för Fabric Data Warehouse utveckling.

Relaterat innehåll

  • Last updated on