Distribuer et lager ved hjelp av pipelines

Gjelder for: ✅ Warehouse i Microsoft Fabric

Microsoft Fabric pipelines gir en strømlinjeformet måte å endre warehouse-skjemaer på tvers av arbeidsområder som Dev → Test → Production. Pipelines har innebygd avhengighetshåndtering, skjemavalidering og deklarativ distribusjonsintelligens.

Important

Denne funksjonen er i forhåndsvisning.

Denne artikkelen forklarer lagerutrullingsprosessen med pipelines.

Diagram over pipeline-distribusjonslivssyklusen for Fabric datalager.

Distribusjonspipelines gir livssyklusstrukturen som trengs for å flytte lagerendringer trygt mellom arbeidsområder. De fungerer som det sentrale orkestreringslaget for skjemapromotering, og lar teamene standardisere hvordan endringer flyter gjennom analyseplattformen i stedet for å stole på ad hoc-distribusjoner. Når den er opprettet, blir pipelinen det primære grensesnittet for å sammenligne lagre, gjennomgå endringer og utføre distribusjoner.

Opprette en pipeline

For å lage en ny pipeline, se Get Start with deployment pipelines for å lage og administrere en distribusjonspipeline.

Compare

Verifiser og sammenlign alltid endringene i T-SQL før utrulling. Distribusjonspipelines tilbyr en enkel sammenligningsskjerm i Fabric-portalen for å gjennomgå de berørte lager-objektene.

Gjennomgang av endringene gjør det mulig for teamene å validere beredskapen før de promoterer oppdateringer til nedstrømsmiljøer. Denne prosessen er spesielt verdifull i bedriftssituasjoner der flere team bidrar til lagerutvikling.

Fabric bruker DacFx (Data-tier Application Framework) for å utføre denne sammenligningen. DacFx bygger en deklarativ skjemamodell for begge miljøene og identifiserer forskjeller som nye tabeller, modifiserte kolonner, begrensninger eller avhengighetsendringer. Fordi denne sammenligningen er modelldrevet, gjenspeiler den nøyaktig hva som skjer under utrulling.

Important

For at skjema-sammenligning skal fungere, må lageret eksistere både i kilde- og målarbeidsområdet. Hvis målarbeidsområdet ennå ikke inneholder lageret, lag eller distribuer en initial baseline-versjon først.

Note

Hvis en kolonnes COLLATE klausul eksplisitt spesifiserer samme kollasjon som lagerets standardkollasjon, viser ikke sammenligningen det som en forskjell, fordi det tilsvarer å ikke spesifisere en kollasjon i det hele tatt. Kun kolonner hvis sammensetning avviker fra lagerets standardsortering vises i sammenligninger når sorteringen endres. For mer informasjon og et eksempel, se Feilsøking av Git-integrasjon for Fabric datalager utvikling.

Før du distribuerer noen endringer, bruk distribusjonspipelinens sammenligningsfunksjon for å gjennomgå forskjeller mellom kilde- og mållagerets arbeidsområder.

Ta skjermbilde i Fabric-portalen ved å bruke en pipeline for å sammenligne et lager i to forskjellige arbeidsområder.

Velg Sammenlign og se endringene, for eksempel å opprette en ny visning i lageret:

Skjermbilde av sammenligningen av et lager i én stat med et lager i en annen stat.

Rull ut

Etter at sammenligningen er ferdig og du har validert endringene, kan du distribuere direkte fra pipeline-grensesnittet ved å velge lagervarene som skal promoteres.

Skjermbilde fra Fabric-portalen av Deploy til denne stage-skjermen i pipelinen.

Under distribusjon bruker distribusjonspipelines DacFx for å generere en intelligent distribusjonsplan basert på skjemaforskjeller. Fabric gjør kun de nødvendige endringene for å bringe målarbeidsområdet synkronisert med kilden.

Skjermbilde fra Fabric-portalen av en vellykket utrulling.

Utplasseringskonfigurasjoner

Fabric distribusjonspipelines bruker DacFx-distribusjonsteknologi med konfigurasjoner skreddersydd spesielt for Fabric datalager. Disse konfigurasjonene sikrer at utrullinger lykkes pålitelig samtidig som de samsvarer med Fabric-plattformens kapasiteter og operative praksiser.

  • Blokkering ved mulig datatap (BlockOnPossibleDataLoss = true) - Fabric datalager forhindrer utrullinger som kan forkorte, droppe eller på annen måte miste brukerdata. Denne innstillingen hindrer at høyrisiko skjemaendringer glipper gjennom CI/CD, og gjør datatapsrisiko til en bevisst beslutning i stedet for en stille standard.

  • Hoppe over databasenivå-opsjonsskripting (ScriptDatabaseOptions = false) - Fabric håndterer mange databasenivåinnstillinger på plattformnivå. Skriptsetninger som ALTER DATABASE ... SET under utrulling kan føre til feil eller utilsiktet konfigurasjonsdrift. Distribusjonspipelines unngår derfor å propagere disse innstillingene, og sikrer at skjemadistribusjoner kun fokuserer på støttede lager-objekter.

  • Tillater motorhåndheving for replikerte objekter (DoNotAlterReplicatedObjects = false) - Lagre bruker ofte interne replikasjonsmekanismer, for eksempel i koblings- eller synkroniseringsscenarier. I stedet for å blokkere skjemaendringer for tidlig, lar distribusjonspipelines Fabric-motoren avgjøre om en endring er tillatt. Denne tilnærmingen forhindrer unødvendige distribusjonsfeil samtidig som plattformens sikkerhet bevares.

  • Deaktivering av transaksjonell DDL-skripting (IncludeTransactionalScripts = false) - Varehus støtter for øyeblikket ikke innpakning av DDL-skript i transaksjoner. Distribusjonspipelines genererer derfor ikke-transaksjonelle skript for å sikre at distribusjonene fullføres med suksess.

  • Bruk av intelligente standardinnstillinger for skjemautvikling (GenerateSmartDefaults = true) - Når skjemaendringer introduserer strengere begrensninger, som å konvertere nullbare kolonner til ikke-nullbare eller legge til nye kolonner med standardbegrensninger, kan distribusjonspipelines automatisk fylle baseline-verdier. Denne tilnærmingen hjelper distribusjoner å lykkes uten å kreve manuell dataforberedelse og reduserer operasjonell friksjon under skjemautviklingen.

  • Ekskludering av sikkerhetsprinsipper fra distribusjon (ExcludeObjectTypes = Logins, Users, Permissions) - Sikkerhetsobjekter er bevisst utelukket fra warehouse-distribusjoner. Å fremme innlogginger, brukere eller tillatelser på tvers av miljøer kan medføre sikkerhetsrisikoer eller miljøspesifikke konflikter. I stedet bør du administrere adgangskontroll separat gjennom miljøstyring eller identitetsstyringsprosesser.

  • Ikke slippe objekter som ikke er i kilden (DropObjectsNotInSource = false) – Objekter som finnes i målet, men ikke i kilden, blir ikke automatisk droppet. Lagre som holder produksjonen perfekt synkronisert med kildekontroll, kan oppleve dette som begrensende.

Begrensninger

  • Som standard blokkerer systemet tabellfall. Distribusjonsprosessen slipper ikke automatisk objekter som finnes i målet, men ikke i kilden. Dette designet reduserer utilsiktet datatap og forhindrer uventede fjerninger i produksjonen.
  • En vellykket utrulling betyr ikke alltid at alle forespurte endringer ble gjennomført. En utrulling kan rapportere suksess selv om den hopper over en forespurt drop-table-handling, fordi tabelldropp blokkeres som standard. I så fall fullføres distribusjonsoperasjonen, men målet kan fortsatt drive bort fra kildekontrollen til du eksplisitt løser den manglende endringen.
  • For øyeblikket prioriterer distribusjonsprosessen sikkerhet fremfor streng kildeparitet ved å ikke slippe objekter som kun eksisterer i målet.
  • Fabric Deployment-pipelines støtter ikke SQL analytics endpoint-elementet.
  • Tverrpunktavhengigheter, varesekvensering og synkroniseringshull mellom SQL-analyseendepunktet og lageret påvirker arbeidsflytene i Fabric Deployment Pipelines.
  • Å velge relaterte elementer i distribusjonspipelines for Fabric datalager støttes ikke.

Feilsøking av Git-integrasjon

For begrensninger spesifikke for Git-integrasjon, se Begrensninger i Git-integrasjon i artikkelen om Git-integrasjon.

For feilsøking, løsninger og løsninger på vanlige Git-integrasjonsproblemer i Fabric datalager utvikling, se Feilsøking av Git-integrasjon for Fabric datalager utvikling.

Relatert innhold

  • Last updated on