Del via

Kildekontroll for notatblokk og distribusjon

Denne artikkelen forklarer hvordan man bruker Git-integrasjons- og distribusjonspipelines med notatbøker i Microsoft Fabric. Du lærer hvordan du kobler til et repository, administrerer notatbokens kildekode og distribuerer notatbøker på tvers av miljøer.

Før du begynner

  • Koble arbeidsområdet ditt til Git før du fullfører kildekodekontroll-trinnene for notatboken. For oppsettsinstruksjoner, se Kom i gang med Git-integrasjon.
  • Lag notatbokdistribusjonsregler på målfasen (for eksempel Test eller Produksjon), ikke på Utvikling.
  • For å lage distribusjonsregler må du være eier av gjenstanden.

Git-integrering for notatblokk

Fabric-notatbøker støtter Git-integrasjon med Azure DevOps for kildekodekontroll. Du kan versjonere notatbokendringer, samarbeide ved å bruke greiner, og administrere notatboklivssyklusoppdateringer direkte i Fabric.

Når du committer en notatbok sammen med tilknyttede avhengigheter (for eksempel miljøer), bevarer synkronisering til et annet arbeidsområde disse bindingene. Fabric binder automatisk notatboken til de tilsvarende ressursene i det nye arbeidsområdet.

For å støtte denne oppførselen lagrer Fabric logiske identifikatorer for tilknyttede ressurser i notatbokmetadata. Som et resultat kan Git-differ vise metadataoppdateringer fra fysiske ID-er til logiske ID-er.

Merk

Metadataoppdateringer knyttet til logiske ID-er og autobinding kan dukke opp i Git-diff-visninger selv når notatbokkoden ikke endres.

Konfigurere en tilkobling

Fra arbeidsområdets innstillinger, sett opp en tilkobling til repositoriet ditt for å committe og synkronisere endringer. For oppsettsinstruksjoner, se Kom i gang med Git-integrasjon. Etter at du har koblet til, vises elementene dine, inkludert notatbøker, i Kildekodekontrollpanelet .

Skjermbilde av kontrollpanelet for kilde for arbeidsområde.

Etter at du committer notatbokinstanser til Git-repositoriet, kan du se notatbokmappestrukturen i repositoriet.

Du kan nå utføre Git-operasjoner, som for eksempel Lag pull request.

Notatblokkpresentasjon i Git

Følgende tekst viser filstrukturen for et notatblokkelement i Git-repositoriet:

.
├── Notebook_1.Notebook/
│   ├── Resources/ (Optional)
│   │   └── builtin/
│   │       ├── large_dataset.parquet
│   │       └── model_output.parquet
│   ├── .platform
│   ├── fs-settings.json (Optional)
│   ├── notebook-content.py
│   └── notebook-settings.json (Optional)
└── Readme.md

.
├── Notebook_2.Notebook/
│   ├── Resources/ (Optional)
│   │   └── builtin/
│   │       ├── large_dataset.parquet
│   │       └── model_output.parquet
│   ├── .platform
│   ├── fs-settings.json (Optional)
│   ├── notebook-content.sql
│   └── notebook-settings.json (Optional)
└── Readme.md

Når du committer et notatbokelement, lagrer Fabric det som kildefiler i stedet for en standardfil .ipynb . For eksempel lagres en PySpark-notatbok som notebook-content.py. Dette formatet er lettere å gjennomgå i Git-differ.

Kildefilen beholder notatbokens metadata (inkludert standard lakehouse og tilknyttet miljø), markdown-celler og kodeceller som separate seksjoner. Fabric bruker denne strukturen til å rekonstruere notatboken når du synkroniserer tilbake til et arbeidsområde.

Celleutdata i notatblokken er ikke inkludert når du synkroniserer til Git.

Følgende skjermbilde viser kildeformatet i Git-repositoriet:

Skjermbilde av innholdsformatet Git-repositorium for notatblokken.

Merk

Hold notatbøker og deres avhengige miljøer i samme arbeidsområde, og gjør både notatblokk- og miljøelementer i Git. Fabric kartlegger disse relasjonene når du synkroniserer til nye arbeidsområder.

Standard Lakehouse-ID forblir i notatbokens metadata når du synkroniserer fra repositoryet til et Fabric-arbeidsområde. Om nødvendig, bind notatboken manuelt til det nye lakehouse-objektet. Hvis du vil ha mer informasjon, kan du se Lakehouse Git-integrasjon.

Notebook Git-innstillinger

Git-innstillingspanelet lar deg kontrollere hvordan notatbøker samhandler med kildekodekontroll, inkludert alternativer for Git-binding og håndtering av hvilke Resources-mapper som inkluderes i commits.

Merk

Ikke rediger notebook-settings.json i Git-repositoriet for å kontrollere Git-autobinding eller ressurser. Administrer disse innstillingene via notatbokens innstillingsside i stedet.

Lakehouse Auto-binding i Git

Lakehouse Auto-Binding lar Fabric bestemme riktig standard lakehouse for hvert Git-tilkoblet arbeidsområde. Dette reduserer manuell ombinding når du flytter notatbøker mellom utviklings-, test- og produksjonsarbeidsområder.

Aktiver denne funksjonen fra notatbokens innstillinger. Etter at du har aktivert det, oppretter notebook-settings.json Fabric filen i repositoriet og administrerer denne filen automatisk. Ikke rediger denne filen manuelt.

Skjermbilde av notebook git-binding.

Merk

Notebook Git-integrasjon støtter å opprettholde bindingsforholdet mellom notatbøker og deres tilknyttede lakehouses ved synkronisering på tvers av arbeidsområder. Når du synkroniserer en notatbok med et annet arbeidsområde, kan du velge om den binder til lakehouse i kildearbeidsområdet eller lakehouse i det nye arbeidsområdet. For notatbøker som allerede er versjonert i Git, erstattes den fysiske ID-en til det tilknyttede lakehouse i notatbokens metadata med en logisk ID. Denne endringen kan vises i Git diff-visningen.

Støtte for mapper for notatbøker i Git

Merk

Environment Resources-mappen og integrasjon med distribusjonspipelines og offentlige API-er støttes for øyeblikket ikke.

Den innebygde Resources-mappen kan settes inn i Git slik at skript og konfigurasjonsfiler blir versjonsjustert med notatboken.

Denne funksjonen er valgfri og av som standard. Aktiver det fra notatbokens innstillinger i Git-innstillingene. Etter at du har aktivert det, blir filer i Resources-mappen inkludert i commits. Siden commits har en grense på 50 MB , bruk .gitignore fil- eller Git-regler for å ekskludere store eller midlertidige filer eller mapper.

Skjermbilde av notatbokens ressurser i git-konfigurasjon.

Merk

Kun i .gitignore den innebygde ressursrotmappen trer i kraft.

Etter at du har konfigurert Git-regler og kommittert endringer, lagrer Fabric reglene fs-settings.json i repositoriet. Fabric genererer og administrerer denne filen for å holde repository-konfigurasjonen konsistent. Vi anbefaler heller ikke å redigere denne filen direkte i Git-repositoriet.

Skjermbilde av notatbokens ressursstruktur i git-konfigurasjon.

Notatblokk i utrullingssamlebånd

Bruk distribusjonspipelines for å fremme endringer i notatboken på tvers av stadier som utvikling, test og produksjon. Valider oppdateringer i tidligere faser før du promoterer dem til produksjon.

Notebook-distribusjon støtter automatisk binding for standard lakehouse og tilknyttet miljø når avhengige elementer er i samme arbeidsområde. Under utrulling kan Fabric binde disse avhengighetene på nytt til tilsvarende elementer i målarbeidsområdet. Metadataendringer kan vises i differensialvisningen.

Hvis du trenger et spesifikt måltrinns standard lakehouse, konfigurer en distribusjonsregel for å overstyre autobinding.

Det nye UI-grensesnittet for distribusjonspipelinen brukes for øyeblikket i denne artikkelen. Du kan bytte til det gamle brukergrensesnittet ved å slå av New Deployment-pipeline.

Merk

Kjent problem: Status for frosne celler i notatbøker bevares ikke under utrulling.

Bruk følgende steg for å distribuere notatbøker gjennom en distribusjonspipeline.

  1. Lag en distribusjonspipeline, eller åpne en eksisterende. 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, se og sammenlign elementer, inkludert notatbøker, mellom stadier. Det markerte merket viser antall endrede gjenstander mellom forrige og nåværende etappe.

    Skjermbilde av notatblokken i utrullingssamlebåndet.

  4. Velg Deploy for å promotere notatbøker på tvers av utviklings-, test- og produksjonsfasene .

    Skjermbilde av utvalgte elementer og distribuer.

  5. I vinduet Deploy to this stage , se på de nye og endrede elementene. For å fortsette utrulling selv om ett eller flere elementer feiler, velg Fortsett utrulling hvis ett eller flere elementer feiler.

    Etter at du har gjennomgått og bekreftet valget, velg Deploy.

    Skjermbilde av distribuer innhold pop-up.png.

  6. (Valgfritt.) For å lage distribusjonsregler, velg Distribusjonsregler på målstadiet i pipelinen (for eksempel Test eller Produksjon).

    For generell regeladferd og begrensninger, se Lag distribusjonsregler.

    Skjermbilde av oppføring av distribusjonsregler.

  7. Konfigurer en standard lakehouse-regel for hver notebook-distribusjon.

    Denne regelen styrer hvilket lakehouse notatboken kobles til i målfasen etter utplassering.

    I panelet Sett utrullingsregler , velg Default lakehouse-flisen .

    Bruk From- og To-nedtrekkslistene for å kartlegge kildestadiet standard innsjøhus til målstadiet standard innsjøhus:

    • Det samme gjelder kilde innsjøhus: Behold samme standard innsjøhusinnstilling som kildestadiet.
    • N/A (ingen standard lakehouse): Fjern standard lakehouse-innstillingen i målfasen.
    • Annet: Bytt ut standardinnsjøhuset i kildestadiet med et annet innsjøhus i målfasen.

    Hvis du velger Annet i Til-nedtrekksmenyen, oppgi detaljer om målet for innsjøhuset:

    • Lakehouse ID
    • Navn på innsjøhuset
    • Lakehouse arbeidsområde-ID

    Skjermbilde av angi standard lakehouse.

    Merk

    Lakehouse-ID kreves når du konfigurerer denne regelen. Du kan få lakehouse-ID-en fra objekt-URL-en. Distribusjonsregler har prioritet over automatisk binding. Hvis en utplasseringsregel konfigureres, overstyrer den den automatisk innbundne innsjøhuset.

  8. Overvåk distribusjonsstatusen fra distribusjonsloggen.

Relatert innhold

  • Last updated on