Kildekontroll, CI/CD og ALM for Fabric dataagent

Denne artikkelen beskriver hvordan man administrerer Fabric-dataagenter ved bruk av Git-integrasjon og distribusjonspipelines som en del av Microsoft Fabric sin Application Lifecycle Management (ALM)-funksjonalitet. Du lærer hvordan du kobler et arbeidsområde til et Git-repositorium. Du vil også lære hvordan du sporer og versjonerer konfigurasjoner av dataagenter. Til slutt lærer du hvordan du promoterer oppdateringer på tvers av utviklings-, test- og produksjonsmiljøer. Git-integrasjons- og distribusjonssamlebånd muliggjør kontinuerlig integrasjon og kontinuerlig distribusjon (CI/CD) av dataagentendringer, slik at oppdateringer kan testes og promoteres automatisk som en del av ALM-arbeidsflyten. Kildekode for Fabric-dataagenter er for øyeblikket i forhåndsvisning.

Du kan bruke to komplementære tilnærminger for å støtte ALM for Fabric-dataagenter:

• Git-integrasjon: Synkroniser et helt arbeidsområde med et Git-repositorium (enten Azure DevOps eller GitHub som en Git-leverandør) for å muliggjøre versjonskontroll, samarbeid gjennom grener og historikksporing for individuelle elementer, inkludert Fabric-dataagenter.
• Utrullingssamlebånd: Hev innhold mellom separate arbeidsområder som representerer utviklings-, test- og produksjonsfaser ved hjelp av innebygde pipeliner.

Disse funksjonene gir til sammen ende-til-ende ALM-støtte for Fabric-dataagenter.

Forutsetninger

• A betalt F2 eller høyere Fabric kapasitet, eller en Power BI Premium per kapasitet (P1 eller høyere) kapasitet med Microsoft Fabric aktivert.
• Aktiver cross-geo prosessering og cross-geo lagring for AI basert på kravene som er beskrevet i Fabric data agent tenant-innstillingene.
• Minst én av disse datakildene, med data: Et lager, et innsjøhus, en Power BI-semantisk modell, en KQL-database, en speilet database eller en ontologi. Du må ha lesetilgang til datakilden.

Git-integrering

Microsoft Fabric Git-integrasjon synkroniserer et Fabric-arbeidsområde med et Git-repository, slik at du kan bruke eksisterende utviklingsprosesser, verktøy og beste praksis direkte i Fabric-plattformen. Den støtter Azure DevOps og GitHub og er tilgjengelig på arbeidsområdenivå. Når du commiter endringer fra Fabric, inkludert oppdateringer til dataagent-konfigurasjonen, lagres disse endringene som filer i det tilkoblede Git-repositoriet. Dens viktigste funksjoner inkluderer:

• Full sikkerhetskopiering og versjonskontroll av arbeidsområdeelementer
• Mappestrukturen i Git speiler arbeidsområdestrukturen
• Dataagentkonfigurasjoner (skjemavalg, AI-instruksjoner, datakildeinstruksjoner, eksempelspørringer) lagres i strukturerte filer i dedikerte mapper
• Mulighet til å vise forskjeller, se gjennom logg og gå tilbake til tidligere tilstander via logg for ulike arbeidsområdeelementer, inkludert dataagenter
• Grenbasert samarbeid (funksjonsgrener, hoved)

Siste forbedringer i Git-integrasjon

Fabric Git-integrasjon støtter nå selektiv forgrening, slik at du kan bytte den tilkoblede grenen på arbeidsområdenivå for å tilpasse seg arbeidsflyter for funksjonsgrener. Kildekontrollpanelet gir også en innebygd differensialopplevelse for itemendringer, slik at du kan gjennomgå nøyaktig hva som har endret seg før du committer eller henter oppdateringer. Forgrenede arbeidsområder er tydeligere angitt i Fabric-grensesnittet, noe som gjør det enklere å identifisere hvilken gren hvert arbeidsområde er koblet til.

Hvis du vil ha mer informasjon om Git-integreringsprosessen, kan du se følgende ressurser.

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

Konfigurere en tilkobling til kildekontroll

Du kan koble arbeidsområdet ditt til Fabric til et Git-repositorium fra siden Workspace settings. Denne tilkoblingen lar deg committe og synkronisere endringer direkte fra Fabric.

1. Se Kom i gang med Git-integrasjon for detaljerte steg for å koble til et Git-repositorium i Azure DevOps eller GitHub.

2. Etter tilkobling til Git-repositoriet vises arbeidsområdets elementer, inkludert Fabric-dataagenter, i Source-kontrollpanelet. På statuslinjen nederst til venstre kan du se navnet på den tilkoblede grenen, tidspunktet for siste synkronisering og Git-commit-ID-en.

3. Det koblede Git-repositoriet viser en mappestruktur som representerer arbeidsområdets elementer, inkludert Fabric-dataagenter og deres konfigurasjonsfiler. Hver dataagent lagres i sin egen mappe, slik at du kan se gjennom endringer, spore versjonslogg og bruke Git-arbeidsflyter, for eksempel å opprette pull-forespørsler for å slå sammen oppdateringer til hovedgrenen.

4. Når du gjør endringer i Fabric-dataagenten i et Git-tilkoblet arbeidsområde, blir endringene oppdaget og dataagentens status i kildekontrollpanelet endres til Uncommitted endringer. Disse modifikasjonene kan omfatte:

   • Endre skjemavalget.
   • Oppdatering av AI-instruksjoner eller instruksjoner for datakilder.
   • Redigere eksempelspørringer.
   • Publisere dataagenten eller oppdatere publiseringsbeskrivelsen.

Enhver endring – enten den er funksjonell eller beskrivende – fører til at dataagenten ikke er synkronisert med det koblede Git-repositoriet. Arbeidsområdeelementene med endringer vises under kategorien Endringer i Kilde-kontrollruten. Du kan se gjennom disse endringene, sammenligne dem med den forpliktede versjonen og sende dem tilbake til Git-repositoriet for å synkronisere.

5. Når oppdateringer gjøres direkte i det lenkede Git-repositoriet (Azure DevOps eller GitHub), kan de inkludere handlinger som å endre AI-instruksjoner, endre eksempelforespørsler eller redigere publiseringsbeskrivelser. Du kan deretter utføre og sende disse endringene til depotet. Når oppdateringene er pushet og tilgjengelige i repositoryet, oppdager Fabric-arbeidsområdet ditt dem og viser en varsling om tilgjengelige oppdateringer i kildekodepanelet. De oppdaterte elementene, for eksempel dataagent, vises under kategorien Oppdateringer, der du kan se gjennom og godta dem. Hvis du godtar disse oppdateringene, brukes repositoriumendringene på arbeidsområdeelementene, noe som sikrer at arbeidsområdet gjenspeiler den siste bekreftede versjonen i Git.

Mappe- og filstruktur i Git-repositoriet

I det følgende gjennomgår du strukturen for hvordan en dataagents konfigurasjon lagres i et Git-repositorium. Å forstå denne strukturen er viktig for å håndtere endringer og følge beste praksis. Når du bruker feature branches, gjør endringer i grenen knyttet til arbeidsområdet, gjennomgå diffs i kildekontrollpanelet , og slå sammen via pull requests for kontrollert promotering. Filene og konfigurasjonsstrukturen for dataagenter forblir den samme på tvers av grener.

Rot struktur

I roten lagres dataagentinnholdet under filmappen . Inne i filer finner du en konfigurasjonsmappe som inneholder data_agent.json, publish_info.json, utkastmappe og publisert mappe.

I konfigurasjonsmappen inneholder publish_info.json publiseringsbeskrivelsen for dataagenten. Denne filen kan oppdateres for å endre beskrivelsen som vises når dataagenten publiseres.

Kladdemappen inneholder konfigurasjonsfilene som tilsvarer utkastversjonen av dataagenten, og den publiserte mappen inneholder konfigurasjonsfilene for den publiserte versjonen av dataagenten. Utkastmappen inneholder:

• Datakildemapper der det finnes én mappe for hver datakilde som brukes av dataagenten.
  • Datakilder for innsjøhus eller lager: Mappenavn starter med lakehouse-tables- eller warehouse-tables-etterfulgt av navnet på innsjøhuset eller lageret.
  • Datakilder for semantisk modell: Mappenavn starter med semantic-model-, etterfulgt av navnet på den semantiske modellen.
  • KQL-databasedatakilder: Mappenavn starter med kusto-, etterfulgt av navnet på KQL-databasen.
  • Ontologidatakilder: Mappenavn begynner med ontology-, etterfulgt av navnet på ontologien.

• stage_config.json som inneholder aiInstructions, som refererer til agentinstruksjonene.

Hver datakildemappe inneholder datasource.json og fewshots.json. Hvis datakilden imidlertid er en semantisk modell, støtter den ikke eksempelspørringer, så mappen inneholder bare datasource.json.

datasource.json definerer konfigurasjonen for denne datakilden, inkludert:

• dataSourceInstructions, som representerer instruksjonene for denne datakilden.

• displayName, som viser navnet på datakilden.

• elements, som refererer til skjemakartet og inneholder en fullstendig liste over tabeller og kolonner fra datakilden.

  • Hvert bord har en is_selected egenskap. Hvis true, er tabellen inkludert, og hvis false, betyr det at tabellen ikke er valgt og ikke vil bli brukt av dataagenten.
  • Kolonneoppføringer viser is_selectedogså , men valg på kolonnenivå støttes ikke for øyeblikket. Hvis en tabell er valgt, inkluderes alle kolonnene uavhengig av kolonneverdien is_selected . Hvis en tabell ikke er valgt (is_selected: false på tabellnivå), vurderes ingen av kolonnene til tross for at den is_selected er satt til true på kolonnenivå.

• Type konvensjoner:

  • Hvis typen er en datakilde, er det ganske enkelt datakildetypen (for eksempel: "type": "lakehouse_tables").
  • Hvis typen er en tabell, slutter den med .table (for eksempel: "type": "lakehouse_tables.table").
  • Hvis typen er en kolonne, slutter den med .column (for eksempel: "type": "lakehouse_tables.column").

fewshots.json lagrer eksempelspørringer for datakilden. Hver oppføring inkluderer:

• id som den unike identifikatoren for eksempelspørringen.
• question, som refererer til spørsmålet om naturlig språk.
• query viser spørringsteksten, som kan være SQL eller KQL, avhengig av datakildetypen.

Den publiserte mappen gjenspeiler strukturen til kladdemappen, men representerer den publiserte versjonen av dataagenten. Det er anbefalt fremgangsmåte å ikke endre filer i den publiserte mappen direkte. Endringer bør gjøres i kladdemappen. Når dataagenten er publisert, gjenspeiles disse endringene i den publiserte mappen. Dette sikrer at den publiserte versjonen alltid genereres fra en kontrollert utkasttilstand.

Utrullingssamlebånd for dataagenter

Utrullingssamlebånd gir en kontrollert måte å flytte dataagenter mellom arbeidsområder som er tilordnet til ulike livssyklusstadier. Eksempel:

1. Utvikle en ny dataagent eller oppdater en eksisterende i utviklingsarbeidsområdet.
2. Hev endringene i testarbeidsområdet for validering.
3. Hev de testede endringene til produksjonsarbeidsområdet der det er tilgjengelig for sluttbrukere.

Før du distribuerer, må du tilordne et arbeidsområde til hver fase i utrullingssamlebåndet: utvikling, testing og produksjon. Hvis du ikke tildeler et arbeidsområde til test- eller produksjonsstadiet, blir arbeidsområdene automatisk opprettet. De automatisk opprettede arbeidsområdene er oppkalt etter utviklingsarbeidsområdet, med [test] eller [prod] tilføyd.

Slik distribuerer du endringer:

• Gå til fasen du vil distribuere fra (for eksempel utvikling) i datasamlebåndet.
• Velg elementene i arbeidsområdet du vil distribuere.
• Velg Distribuer for å heve dem til neste fase.

Du kan se gjennom en distribusjonsplan før du tar i bruk endringer, og sikre at bare tiltenkte oppdateringer fremmes. Hvis du vil ha mer informasjon, kan du se Komme i gang med utrullingssamlebånd.

Automate CI/CD with Azure DevOps Pipelines

Azure DevOps Pipelines-utvidelsen for Fabric tilbyr native oppgaver som kjører Fabric CLI kommandoer i Azure DevOps pipeline-jobber. Teams kan orkestrere CI/CD for oppdateringer av dataagenter ved å bruke Azure DevOps (med CLI) sammen med eller i stedet for Fabric-distribusjonspipelines. For å komme i gang, installer utvidelsen fra Visual Studio Marketplace, sett opp en servicetilkobling i Azure DevOps-prosjektet ditt, og legg til Fabric CLI-oppgaver i pipeline-definisjonen din.

Bulk-synkronisering via batch-API-er (forhåndsvisning)

Import/Export Item Definitions Batch API-ene (forhåndsvisning) gir et alternativ for storskala synkronisering av varedefinisjoner, inkludert dataagent-konfigurasjoner. Du kan eksportere og importere dataagentdefinisjoner i batch for å effektivisere promotering på tvers av miljøer. For mer informasjon, se dokumentasjonen Fabric REST API.

Note

Tjenesteprinsipper støttes i Fabric dataagent kun som en del av ALM-scenarier. Denne støtten er begrenset til å aktivere ALM-operasjoner (som Git-integrasjon og distribusjonspipelines) og gjelder ikke andre funksjoner i Fabric-dataagenten. Hvis du trenger å samhandle med en dataagent utenfor ALM-arbeidsflyter, støttes ikke tjenestekontohaver.

Publiser en Fabric-dataagent for distribusjonspipelinene

Ved å publisere en Fabric-dataagent blir den tilgjengelig for bruk på tvers av alle ulike forbrukskanaler, inkludert Copilot for Power BI, Microsoft Copilot Studio og Foundry Tools. Hvis du vil vurdere og bruke dataagenten på tvers av disse kanalene, må dataagenten publiseres. Upubliserte dataagenter er ikke tilgjengelige for forbruk selv om de er i produksjonsarbeidsområdet. For å følge de anbefalte fremgangsmåtene i samsvar med distribusjonspipelinen må du være oppmerksom på at:

• Publisering fra et utviklingsarbeidsområde bør begrenses til bare autoriserte brukere som arbeider med utvikling av dataagenter og ønsker å vurdere ytelsen på tvers av ulike forbrukskanaler. Tilgang til dette arbeidsområdet må begrenses slik at uferdige eller eksperimentelle dataagenter ikke eksponeres for bredere publikum.
• Sluttbrukere bør få tilgang til dataagenter som bare publiseres fra produksjonsarbeidsområdet, og sikre at de samhandler med stabile, godkjente versjoner av dataagenten.

Denne tilnærmingen støtter både det funksjonelle kravet om å muliggjøre forbruk og ytelsesevaluering, og den sikrer riktig tilgangskontroll ved å holde utviklings- og produksjonsmiljøer atskilt.

Beste fremgangsmåter

• Bruk en dedikert gren for utviklingsarbeid på dataagenter, og slå sammen til hoved etter kodegjennomgang.
• Oppbevar relaterte ressurser (datakilder, dataagenter, notatblokker, datasamlebånd) i samme arbeidsområde for enklere promotering.
• Testdataagenten endres i testarbeidsområdet før den forfremmes til produksjon.
• Bruk beskrivende utførelsesmeldinger for å gjøre historikken enklere å forstå.
• Ikke gjør endringer direkte i den publiserte mappen i Git-repositoriet.
• Bruk miljøuavhengige konfigurasjonsmønstre (for eksempel tilkoblingsreferanser via variabelbibliotek der det støttes) for å unngå hardkoding av miljøspesifikke verdier i datakildekonfigurasjoner for dataagenter. Denne praksisen legger til rette for smidigere sammenslåinger og distribusjoner av grener på tvers av utvikling, test og produksjon.

Begrensninger og vurderinger

• Bare arbeidsområder som er koblet til et Git-repositorium, kan bruke Git-baserte ALM-funksjoner.
• Tjenesteprinsipper støttes kun i Fabric-dataagenten som en del av ALM-scenarier. Hvis du trenger å samhandle med en dataagent utenfor ALM-arbeidsflyter, støttes ikke tjenestekontohaver.
• Utrullingssamlebånd krever at kilde- og målarbeidsområdene er i samme leier.
• Et stort antall hyppige forpliktelser kan påvirke repositoriets størrelse og ytelse.

Relatert innhold

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