Kildekontroll, CI/CD og ALM for Fabric-dataagent (forhåndsversjon)

Denne artikkelen beskriver hvordan du administrerer Fabric-dataagenter ved hjelp av Git-integrerings- og distribusjonssamlebånd som en del av Microsoft Fabrics funksjoner for administrasjon av programlivssyklus (ALM). Du lærer hvordan du kobler et arbeidsområde til et Git-repositorium. Du lærer også hvordan du sporer og versjonerer dataagentkonfigurasjoner. 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. Kildekontroll for Fabric-dataagenter er for øyeblikket i forhåndsversjon.

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

• Git-integrering: Synkroniser et helt arbeidsområde med et Git-repositorium (enten Azure DevOps eller GitHub som Git-leverandør) for å muliggjøre versjonskontroll, samarbeid gjennom grener og loggsporing 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 sammen ende-til-ende-ALM-støtte for Fabric-dataagenter.

Viktig!

Denne funksjonen er i forhåndsvisning.

Forutsetninger

• En betalt F2 eller høyere Fabric-kapasitet, eller en Power BI Premium per kapasitet (P1 eller høyere) kapasitet med Microsoft Fabric aktivert
• Leierinnstillinger for fabric-dataagenten er aktivert.
• kryss-geo-behandling for AI- er aktivert.
• kryss-geo lagring for AI- er aktivert.
• Minst én av disse, med data: Et lager, et lakehouse, en eller flere Power BI semantiske modeller, en KQL-database eller en ontologi.
• Power BI-semantiske modeller via XMLA-endepunkter-leierbryteren er aktivert for datakilder for semantisk power BI-semantisk modell.

Git-integrering

Microsoft Fabric Git-integrasjon synkroniserer et Fabric-arbeidsområde med et Git-repositorium, slik at du kan bruke eksisterende utviklingsprosesser, verktøy og anbefalte fremgangsmåter direkte i Fabric-plattformen. Den støtter Azure DevOps og GitHub og er tilgjengelig på arbeidsområdenivå. Når du utfører endringer fra Fabric, inkludert oppdateringer av dataagentkonfigurasjonen, 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)

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

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

Konfigurere en tilkobling til kildekontroll

Du kan koble Fabric-arbeidsområdet til et Git-repositorium fra siden Innstillinger for arbeidsområde . Med denne tilkoblingen kan du utføre og synkronisere endringer direkte fra Fabric.

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

2. Når du har koblet til Git-repositoriet, vises arbeidsområdeelementene, inkludert Fabric-dataagenter, i Kilde-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ådeelementene, 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, oppdages endringene, og dataagentens status i Kilde-kontrollruten endres til Ubekreftede 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 koblede Git-repositoriet (Azure DevOps eller GitHub), kan de inkludere handlinger som å endre AI-instruksjoner, endre eksempelspørringer eller redigere publiseringsbeskrivelser. Du kan deretter utføre og sende disse endringene til depotet. Når oppdateringene er overført og tilgjengelige i repositoriet, oppdager Fabric-arbeidsområdet dem og viser et varsel om tilgjengelige oppdateringer i Kilde-kontrollruten. 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 ser du gjennom strukturen for hvordan konfigurasjonen til en dataagent lagres i et Git-repositorium. Å forstå denne strukturen er viktig for å håndtere endringer og følge beste praksis.

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 vises 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 tilordner et arbeidsområde til test- eller produksjonsfasen, opprettes arbeidsområdene automatisk. 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.

Note

Tjenestekontohavere støttes bare i Fabric-dataagenten som en del av ALM-scenarioer. Denne støtten er begrenset til å aktivere ALM-operasjoner (for eksempel Git-integrering og utrullingssamlebånd) og strekker seg ikke til andre Fabric-dataagentfunksjoner. Hvis du trenger å samhandle med en dataagent utenfor ALM-arbeidsflyter, støttes ikke tjenestekontohaver.

Publisere en Fabric-dataagent for utrullingssamlebåndene

Publisering av en Fabric-dataagent gjør den tilgjengelig for bruk på tvers av alle ulike forbrukskanaler, inkludert Copilot for Power BI, Microsoft Copilot Studio og Azure AI Foundry Services. 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.

Begrensninger og vurderinger

• Bare arbeidsområder som er koblet til et Git-repositorium, kan bruke Git-baserte ALM-funksjoner.
• Tjenestekontohavere støttes bare i Fabric-dataagenten som en del av ALM-scenarioer. 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 livssyklusadministrasjon i Microsoft Fabric?