Kildekontroll (forhåndsversjon)

Gjelder for:✅ Warehouse i Microsoft Fabric

Denne artikkelen forklarer hvordan Git-integrasjons- og distribusjonspipelines fungerer for lagre i Microsoft Fabric. Lær hvordan du konfigurerer en tilkobling til repositoriet, administrerer lagrene og distribuerer dem på tvers av ulike miljøer. Kildekode for Fabric Warehouse er for øyeblikket en forhåndsvisningsfunksjon.

Du kan bruke både Git-integrasjon og utrullingssamlebånd for ulike scenarioer:

• Bruk Git- og SQL-databaseprosjekter for å håndtere inkrementelle endringer, teamsamarbeid og commit-historikk i individuelle databaseobjekter.
• Bruk utrullingssamlebånd til å fremme kodeendringer i ulike miljøer før produksjon og produksjon.

Git-integrering

Git-integrasjon i Microsoft Fabric gjør det mulig for utviklere å integrere sine utviklingsprosesser, verktøy og beste praksis direkte i Fabric-plattformen. Det gjør det mulig for utviklere som utvikler i Fabric å:

• Sikkerhetskopier og versjon av arbeidet deres
• Gå tilbake til tidligere faser etter behov
• Samarbeid med andre eller jobb alene ved å bruke Git-grener
• Bruk mulighetene til kjente kildekontrollverktøy for å administrere Fabric-elementer

Hvis du vil ha mer informasjon om Git-integreringsprosessen, kan du se:

• Hva er Microsoft Fabric Git-integrasjon?
• Grunnleggende konsepter i Git-integrasjon
• Kom i gang med Git-integrasjon

Konfigurere en tilkobling til kildekontroll

Fra siden innstillinger for arbeidsområde kan du enkelt konfigurere en tilkobling til repo for å utføre og synkronisere endringer.

1. Hvis du vil konfigurere tilkoblingen, kan du se Komme i gang med Git-integrasjon. Følg instruksjonene for å Connect to a Git repo for enten å Azure DevOps eller GitHub som Git-leverandør.
2. Når de er tilkoblet, vises elementene, inkludert lagre, i kildekontrollpanelet .
3. Når du har koblet lagerforekomstene til Git-repositoriet, ser du lagermappestrukturen i repositoriet. Nå kan du utføre fremtidige operasjoner, som å opprette en pull-forespørsel.

Databaseprosjekter for et lager i Git

Følgende bilde er et eksempel på filstrukturen for hvert lagerelement i repo:

Når du overfører lagervaren til Git-repositoriet, konverteres lageret til et kildekodeformat, som et SQL-databaseprosjekt. Et SQL-prosjekt er en lokal representasjon av SQL-objekter som utgjør skjemaet for én enkelt database, for eksempel tabeller, lagrede prosedyrer eller funksjoner. Mappestrukturen for databaseobjektene er organisert etter skjema-/objekttype. Hvert objekt i lageret representeres med en .sql fil som inneholder definisjonen for datadefinisjonsspråk (DDL). Lagertabelldata og SQL-sikkerhetsfunksjoner er ikke inkludert i SQL-databaseprosjektet.

Delte spørringer forpliktes også til repo og arver navnet de lagres som.

Datasamlebånd for distribusjon

Du kan også bruke utrullingssamlebånd til å distribuere lagerkoden på tvers av ulike miljøer, for eksempel utvikling, test og produksjon. Utrullingssamlebånd viser ikke et databaseprosjekt.

Bruk følgende steg for å fullføre lagerutrullingen ved å bruke distribusjonspipelinen.

1. Opprett et nytt utrullingssamlebånd eller åpne et eksisterende utrullingssamlebånd. Hvis du vil ha mer informasjon, kan du se Komme i gang med utrullingssamlebånd.
2. Tilordne arbeidsområder til ulike faser i henhold til distribusjonsmålene.
3. Velg, vis og sammenlign varer, inkludert lagerbygninger, mellom ulike stadier, som vist i eksempelet nedenfor.
4. Velg Distribuer for å distribuere lagrene på tvers av utviklings-, test- og produksjonsfasene .

For mer informasjon om prosessen for Fabric deployeringspipelines, se Introduction to deployment pipelines.

Begrensninger i kildekontroll

• Du må eksportere eller migrere SQL-sikkerhetsfunksjoner ved å bruke en skriptbasert tilnærming. Vurder å bruke et post-deploying-skript i et SQL-databaseprosjekt. Du kan konfigurere dette skriptet ved å åpne prosjektet med utvidelsen SQL Database Projects tilgjengelig i Visual Studio Code.

Begrensninger i Git-integrering

• For øyeblikket, hvis du bruker ALTER TABLE det for å legge til en begrensning eller kolonne i databaseprosjektet, dropper distribusjonsprosessen tabellen og gjenskaper tabellen, noe som resulterer i datatap. For å bevare tabelldefinisjonen og dataene, vurder følgende løsning:
  • Lag en ny kopi av tabellen i lageret ved å bruke CREATE TABLE og INSERT, CREATE TABLE AS SELECT, eller Klonetabell.
  • Endre den nye tabelldefinisjonen med nye begrensninger eller kolonner, som ønsket, ved å bruke ALTER TABLE.
  • Slett den gamle tabellen.
  • Gi den nye tabellen nytt navn til navnet på den gamle tabellen ved å bruke sp_rename.
  • Endre definisjonen av den gamle tabellen i SQL-databaseprosjektet på nøyaktig samme måte. SQL-databaseprosjektet for lageret i kildekontrollen og det direktesendte lageret skal nå samsvare.
• For øyeblikket, ikke lag en Dataflow Gen2 med en utgangsdestinasjon til lageret. Et nytt element med navn DataflowsStagingWarehouse dukker opp i repositoriet og blokkerer committing og oppdatering fra Git.
• Fabric Git-integrasjon støtter ikke SQL-analyse-endepunktet.
• Tverrpunktavhengigheter, varesekvensering og synkroniseringshull mellom SQL-analyseendepunktet og lageret påvirker arbeidsflytene for «å forgrene seg til et nytt eller eksisterende arbeidsområde» og «bytte til en annen gren» under utvikling og kontinuerlig integrasjon.

Begrensninger for utrullingssamlebånd

• For øyeblikket, hvis du bruker ALTER TABLE det for å legge til en begrensning eller kolonne i databaseprosjektet, dropper distribusjonsprosessen tabellen og gjenskaper tabellen, noe som resulterer i datatap.
• For øyeblikket, ikke lag en Dataflow Gen2 med en utgangsdestinasjon til lageret. Et nytt element med navn DataflowsStagingWarehouse dukker opp i distribusjonspipelinen og blokkerer distribusjon.
• 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.

Scenarier som ikke støttes

Følgende CI/CD-arbeidsflyter støttes ikke offisielt når lagre i forskjellige arbeidsområder har ulike sorteringer. Selv om disse operasjonene kan lykkes uten feil, kan de føre til metadatafeil.

I alle disse situasjonene, hvis det oppstår en kollasjonsmismatch, bruk Python-skriptet scripts/dw-collation-error-update-tmsl/pbi_interactive.py i Fabric toolbox GitHub-repositoriet for å oppdatere datasettets (TMSL)-kollasjon slik at den matcher warehouse-sorteringen.

Relatert innhold

• Utvikling og distribusjon
• Kom i gang med Git-integrasjon