Kildekontroll for notatblokk og distribusjon
Denne artikkelen forklarer hvordan Git-integrerings- og distribusjonssamlebånd fungerer for notatblokker i Microsoft Fabric. Lær hvordan du konfigurerer en tilkobling til repositoriet, administrerer notatblokkene og distribuerer dem på tvers av ulike miljøer.
Git-integrering for notatblokk
Stoffnotatblokker tilbyr Git-integrasjon for kildekontroll med Azure DevOps. Med Git-integrering kan du sikkerhetskopiere og versjonere notatblokken, gå tilbake til tidligere faser etter behov, samarbeide eller arbeide alene ved hjelp av Git-grener og administrere livssyklusen for notatblokken helt i Fabric.
Merk
Fra og med oktober 2024 støtter git-integrering av notatblokk fortsatt tilordningsrelasjonen til det vedlagte miljøet når du synkroniserer til nytt arbeidsområde, noe som betyr at når du forplikter notatblokken og det vedlagte miljøet sammen til git-repositoriet og synkroniserer det til et annet arbeidsområde, blir den nylig genererte notatblokken og miljøet bundet sammen. Denne oppgraderingen vil ha innvirkning på eksisterende notatblokker og avhengige miljøer som er versjonert i git, fysisk ID for vedlagt miljø i metadatainnhold i notatblokken erstattes med en logisk ID, endringen gjenspeiles i diff-visningen.
Konfigurere en tilkobling
Fra innstillingene for arbeidsområdet kan du enkelt konfigurere en tilkobling til repo for å utføre og synkronisere endringer. Hvis du vil konfigurere tilkoblingen, kan du se Komme i gang med Git-integrasjon. Når du er tilkoblet, vises elementene, inkludert notatblokker, i kontrollpanelet for kilde.
Når du har utført notatblokkforekomstene til Git-repositoriet, ser du mappestrukturen for notatblokken i repositoriet.
Nå kan du utføre fremtidige operasjoner, for eksempel Opprett pull-forespørsel.
Notatblokkpresentasjon i Git
Følgende bilde er et eksempel på filstrukturen for hvert notatblokkelement i repo:
Når du overfører notatblokkelementet til Git-repositoriet, konverteres notatblokkkoden til et kildekodeformat, i stedet for en standard .ipynb-fil. En PySpark-notatblokk konverteres for eksempel til en notebook-content.py fil. Denne fremgangsmåten gir enklere kodegjennomganger ved hjelp av innebygde diff-funksjoner.
Metadata (inkludert standard lakehouse og tilknyttet miljø), markdown-celler og kodeceller bevares og skilles i innholdskildefilen for elementet. Denne tilnærmingen støtter en nøyaktig gjenoppretting når du synkroniserer tilbake til et Fabric-arbeidsområde.
Celleutdata i notatblokken er ikke inkludert når du synkroniserer til Git.
Merk
- Filer i notatblokkressurser er for øyeblikket ikke forpliktet til repo. Bruk av disse filene støttes i en kommende versjon.
- Vi anbefaler at du administrerer notatblokkene og deres underordnede miljø i samme arbeidsområde, og bruker git til å styre både notatblokken og miljøelementene , fabric git-systemet håndterer tilordningsrelasjonen når du synkroniserer notatblokken og det vedlagte miljøet til nye arbeidsområder.
- Standard lakehouse-ID beholdes i notatblokken når du synkroniserer fra repo til et stoffarbeidsområde. Hvis du utfører en notatblokk med standard lakehouse, må du henvise til et nyopprettet lakehouse-element manuelt. Hvis du vil ha mer informasjon, kan du se Lakehouse Git-integrasjon.
Notatblokk i utrullingssamlebånd
Du kan også bruke utrullingssamlebånd til å distribuere notatblokkkoden på tvers av ulike miljøer, for eksempel utvikling, test og produksjon. Denne funksjonen kan gjøre det mulig for deg å effektivisere utviklingsprosessen, sikre kvalitet og konsekvens og redusere manuelle feil med lette lavkodeoperasjoner. Du kan også bruke distribusjonsregler til å tilpasse virkemåten til notatblokkene når de distribueres, for eksempel endre standard lakehouse for en notatblokk.
Merk
- Du bruker den nye utformingen av utrullingssamlebåndet nå, det gamle brukergrensesnittet kan nås ved å slå av «Nytt utrullingsforløp».
- Fra og med oktober støtter Fabric-notatblokken automatisk bindingsfunksjon som binder standard lakehouse og tilknyttet miljø i samme arbeidsområde når du distribuerer til neste fase. Endringen vil ha innvirkning på eksisterende notatblokker i utrullingssamlebåndet.
- Standard lakehouse og tilknyttet miljø (når alle avhengige elementer er i samme arbeidsområde) vil bli erstattet av nylig genererte elementer i målarbeidsområdet, endring av metadata for notatblokken utheves i diff-visningen i neste distribusjonsrunde.
- Du kan angi distribusjonsregler for standard lakehouse for å overstyre det automatisk bindede lakehouse.
- Kjent problem: Frossen cellestatus i notatblokken vil gå tapt under distribusjon. Vi arbeider for øyeblikket med relaterte oppgaver.
Bruk følgende fremgangsmåte for å fullføre distribusjonen av notatblokken ved hjelp av utrullingssamlebåndet.
Opprett et nytt utrullingssamlebånd eller åpne et eksisterende utrullingssamlebånd. (Hvis du vil ha mer informasjon, kan du se Kom i gang med utrullingssamlebånd.)
Tilordne arbeidsområder til ulike faser i henhold til distribusjonsmålene.
Velg, vis og sammenlign elementer, inkludert notatblokker mellom ulike faser, som vist i eksemplet nedenfor. Det uthevede merket som angir antall endrede elementer mellom forrige fase og gjeldende fase.
Velg Distribuer for å distribuere notatblokkene på tvers av utviklings-, test- og produksjonsfasene.
(Valgfritt.) Du kan velge distribusjonsregler for å opprette distribusjonsregler for en distribusjonsprosess. Oppføring av distribusjonsregler er på målfasen for en distribusjonsprosess.
Fabric støtter parameterisering av standard lakehouse for hver notatblokkforekomst når du distribuerer med distribusjonsregler. Tre alternativer er tilgjengelige for å angi målet standard lakehouse: Samme med kilde lakehouse, N / A (ingen standard lakehouse), og andre lakehouse.
Du kan oppnå sikret dataisolering ved å konfigurere denne regelen. Standard lakehouse for notatblokken erstattes av den du angav som mål under distribusjon.
Merk
Når du angir standard lakehouse i distribusjonsregler, må Lakehouse-ID-en ha. Du kan få lakehouse-ID-en fra koblingen for nettadressen for elementet. Distribusjonsreglene har høyere prioritet enn automatisk binding. Den automatisk bindede lakehouse blir overskrevet når det er konfigurert distribusjonsregel.
Overvåk distribusjonsstatusen fra distribusjonsloggen.