Udrul et lager ved hjælp af pipelines

Gælder for: ✅ Lager i Microsoft Fabric

Microsoft Fabric pipelines giver en strømlinet måde at ændre warehouse-skemaer på tværs af arbejdsområder som Dev → Test → Production. Pipelines har indbygget afhængighedshåndtering, skemavalidering og deklarativ implementeringsintelligens.

Vigtigt!

Denne funktion er en prøveversion.

Denne artikel forklarer processen for lagerudrulning med pipelines.

Diagram over pipeline-implementeringslivscyklussen for Fabric data warehouse.

Implementeringspipelines leverer den livscyklusstruktur, der er nødvendig for sikkert at flytte lagerændringer på tværs af arbejdsområder. De fungerer som det centrale orkestreringslag for skema-promovering, hvilket gør det muligt for teams at standardisere, hvordan ændringer forløber gennem analyseplatformen i stedet for at stole på ad hoc-implementeringer. Når pipelinen er oprettet, bliver den primære grænseflade til at sammenligne lagre, gennemgå ændringer og udføre implementeringer.

Oprette en pipeline

For at oprette en ny pipeline, se Get Started with deployment pipelines to create and management a deployment pipeline.

Compare

Verificér og sammenlign altid T-SQL-ændringerne før implementering. Deployment pipelines tilbyder en nem sammenligningsskærm i Fabric-portalen for at gennemgå de berørte lagerobjekter.

Gennemgang af ændringerne giver teams mulighed for at validere parathed, før de promoverer opdateringer til downstream-miljøer. Denne proces er særligt værdifuld i virksomhedsscenarier, hvor flere teams bidrager til lagerudviklingen.

Fabric bruger DacFx (Data-tier Application Framework) til at udføre denne sammenligning. DacFx bygger en deklarativ skemamodel af begge miljøer og identificerer forskelle såsom nye tabeller, ændrede kolonner, begrænsninger eller afhængighedsændringer. Fordi denne sammenligning er modeldrevet, afspejler den nøjagtigt, hvad der sker under implementeringen.

Vigtigt!

For at skema-sammenligning skal fungere, skal lageret eksistere både i kilde- og målarbejdsområderne. Hvis målarbejdsområdet endnu ikke indeholder lageret, skal du først oprette eller implementere en indledende baseline-version.

Note

Hvis en kolonnes COLLATE klausul eksplicit specificerer den samme kollation som lagerets standardkollation, viser sammenligningen det ikke som en forskel, fordi det svarer til slet ikke at specificere en kollation. Kun kolonner, hvis sammensætning adskiller sig fra lagerets standard-sammensætning, optræder i sammenligninger, når deres samling ændres. For mere information og et eksempel, se Fejlfinding Git-integration for Fabric data warehouse udvikling.

Før du implementerer ændringer, brug implementeringspipelinens sammenligningsfunktion til at gennemgå forskellene mellem kilde- og mållagerets arbejdsområder.

Tag et screenshot i Fabric-portalen ved at bruge en pipeline til at sammenligne et lager i to forskellige arbejdsområder.

Vælg Sammenlign og se ændringerne, såsom oprettelse af en ny visning i lageret:

Skærmbillede af sammenligningen af et lager i én stat med et lager i en anden stat.

Installér

Når sammenligningen er færdig, og du har valideret ændringerne, kan du implementere direkte fra pipeline-grænsefladen ved at vælge de lagervarer, der skal promoveres.

Screenshot fra Fabric-portalen af Deploy til denne faseskærm i pipelinen.

Under udrulning bruger udrulningspipelines DacFx til at generere en intelligent udrulningsplan baseret på skemaforskelle. Fabric anvender kun de nødvendige ændringer for at bringe målarbejdsområdet i sync med kilden.

Skærmbillede fra Fabric-portalen af en vellykket udrulning.

Udrulningskonfigurationer

Fabric implementeringspipelines bruger DacFx-implementeringsteknologi med konfigurationer, der er skræddersyet specifikt til Fabric data warehouse. Disse konfigurationer sikrer, at implementeringer lykkes pålideligt, samtidig med at de er i overensstemmelse med Fabric-platformens kapaciteter og driftspraksis.

  • Blokering af muligt datatab (BlockOnPossibleDataLoss = true) - Fabric data warehouse forhindrer udrulninger, der kan afkorte, droppe eller på anden måde miste brugerdata. Denne indstilling forhindrer højrisiko-skemaændringer i at slippe igennem CI/CD og gør datatabsrisikoen til en bevidst beslutning i stedet for en stille standard.

  • Springer database-niveau option scripting over (ScriptDatabaseOptions = false) - Fabric håndterer mange database-niveau indstillinger på platformniveau. Scripting-sætninger, såsom ALTER DATABASE ... SET under udrulning, kan føre til fejl eller utilsigtet konfigurationsdrift. Deployment pipelines undgår derfor at udbrede disse indstillinger og sikrer, at schema-udrulninger kun fokuserer på understøttede warehouse-objekter.

  • Tillader motorhåndhævelse for replikerede objekter (DoNotAlterReplicatedObjects = false) - Lagre bruger ofte interne replikeringsmekanismer, for eksempel i linking- eller synkroniseringsscenarier. I stedet for at blokere skemaændringer for tidligt, tillader deployment-pipelines Fabric-motoren at afgøre, om en ændring er tilladt. Denne tilgang forhindrer unødvendige implementeringsfejl, samtidig med at platformens sikkerhed bevares.

  • Deaktivering af transaktionel DDL-scripting (IncludeTransactionalScripts = false) - Lagre understøtter i øjeblikket ikke indpakning af DDL-scripts i transaktioner. Udrulningspipelines genererer derfor ikke-transaktionelle scripts for at sikre, at implementeringerne gennemføres med succes.

  • Brug af intelligente standardindstillinger for skemaudvikling (GenerateSmartDefaults = true) - Når skemaændringer introducerer strengere begrænsninger, såsom at konvertere nullbare kolonner til ikke-nullbare eller tilføje nye kolonner med standardbegrænsninger, kan deployment pipelines automatisk udfylde baseline-værdier. Denne tilgang hjælper implementeringer med at lykkes uden at kræve manuel dataforberedelse og reducerer operationel friktion under skemaudviklingen.

  • Udelukkelse af sikkerhedsprincipper fra deployment (ExcludeObjectTypes = Logins, Users, Permissions) - Sikkerhedsobjekter udelukkes bevidst fra warehouse-deployments. Fremme af logins, brugere eller tilladelser på tværs af miljøer kan medføre sikkerhedsrisici eller miljøspecifikke konflikter. I stedet skal adgangskontrol håndteres separat gennem miljøstyring eller identitetsstyringsprocesser.

  • Ikke at droppe objekter, der ikke er i kilden (DropObjectsNotInSource = false) - Objekter, der findes i målet, men ikke i kildekoden, bliver ikke automatisk droppet. Lagre, der holder produktionen perfekt synkroniseret med versionskontrol, kan finde dette begrænsende.

Begrænsninger

  • Som standard blokerer systemet tabell-drops. Udrulningsprocessen dropper ikke automatisk objekter, der findes i målet, men ikke i kildekoden. Dette design reducerer utilsigtet datatab og forhindrer uventede fjernelser i produktionen.
  • En vellykket udrulning betyder ikke altid, at alle anmodede ændringer blev anvendt. En udrulning kan rapportere succes, selv når den springer en anmodet drop-table-handling over, fordi table drops som standard blokeres. I så fald fuldføres deployment-operationen, men målet kan stadig drive væk fra versionskontrol, indtil du eksplicit løser den manglende ændring.
  • Fabric Deployment-pipelines understøtter ikke SQL analytics endpoint-elementet. I øjeblikket prioriterer udrulningsprocessen sikkerhed frem for streng kildeparitet ved ikke at droppe objekter, der kun findes i målet.
  • Afhængigheder på tværs af items, item sequencing og synkroniseringshuller mellem SQL-analyseendpointet og lageret påvirker Fabric Deployment Pipelines workflows.
  • Med Fabric Deployment-pipelines kan du kun deploye ét lager ad gangen. At vælge relaterede elementer til udrulning understøttes ikke.

Fejlfinding af Git-integration

For begrænsninger specifikke for Git-integration, se Begrænsninger i Git-integration i artiklen om Git-integration.

For fejlfinding, løsninger og rettelser til almindelige Git-integrationsproblemer i Fabric data warehouse udvikling, se Fejlfinding af Git-integration for Fabric data warehouse udvikling.

Relateret indhold

  • Last updated on