Versionskontrol, CI/CD og ALM for Fabric dataagent

Denne artikel beskriver, hvordan man administrerer Fabric-dataagenter ved hjælp af Git-integration og deploymentspipelines som en del af Microsoft Fabric's Application Lifecycle Management (ALM)-funktioner. Du lærer, hvordan du forbinder et arbejdsområde til et Git-lager. Du får også mere at vide om, hvordan du sporer og udvælger konfigurationer af dataagenter. Endelig lærer du, hvordan du promoverer opdateringer på tværs af udviklings-, test- og produktionsmiljøer. Git-integrations- og udrulningspipelines muliggør løbende integration og løbende udrulning (CI/CD) af dataagentændringer, så opdateringer kan testes og promoveres automatisk som en del af din ALM-arbejdsproces. Versionskontrol for Fabric-dataagenter er i øjeblikket i preview.

Du kan bruge to komplementære tilgange til at understøtte ALM for Fabric dataagenter:

• Git-integration: Synkroniser et helt arbejdsområde med et Git-repository (enten Azure DevOps eller GitHub som en Git-udbyder) for at muliggøre versionskontrol, samarbejde gennem branchs og historiksporing for individuelle elementer, herunder Fabric-dataagenter.
• Udrulningspipelines: Hæv indhold mellem separate arbejdsområder, der repræsenterer udviklings-, test- og produktionsfaser ved hjælp af indbyggede pipelines.

Disse funktioner giver tilsammen end-to-end ALM-understøttelse for Fabric-dataagenter.

Forudsætninger

• A betalt F2 eller højere Fabric kapacitet, eller en Power BI Premium pr. kapacitet (P1 eller højere) kapacitet med Microsoft Fabric aktiveret.
• Aktiver cross-geo behandling og cross-geo lagring for AI baseret på krav, der er beskrevet i Fabric data agent tenant-indstillingerne.
• Mindst én af disse datakilder, med data: Et lager, et søhus, en Power BI semantisk model, en KQL-database, en spejlet database eller en ontologi. Du skal have læseadgang til datakilden.

Integration af gitter

Microsoft Fabric Git-integration synkroniserer et Fabric-arbejdsområde med et Git-repository, så du kan bruge dine eksisterende udviklingsprocesser, værktøjer og best practices direkte i Fabric-platformen. Den understøtter Azure DevOps og GitHub og er tilgængelig på arbejdsområdeniveau. Når du commmitter ændringer fra Fabric, inklusive opdateringer til dataagent-konfigurationen, gemmes disse ændringer som filer i det tilsluttede Git-repository. Dens vigtigste funktioner omfatter:

• Fuld sikkerhedskopiering og versionskontrol af arbejdsområdeelementer
• Mappestrukturen i Git afspejler arbejdsområdets struktur
• Dataagentkonfigurationer (skemavalg, AI-instruktioner, datakildeinstruktioner, eksempelforespørgsler) gemmes i strukturerede filer i dedikerede mapper
• Mulighed for at se forskelle, gennemse historik og vende tilbage til tidligere tilstande via historik for forskellige arbejdsområdeelementer, herunder dataagenter
• Forgreningsbaseret samarbejde (funktionsforgreninger, hoved)

Seneste forbedringer af Git-integration

Fabric Git-integration understøtter nu selektiv branching, så du kan skifte den tilsluttede branch på workspace-niveau, så den tilpasses feature branch-workflows. Versionskontrolpanelet giver også en indbygget diff-oplevelse for vareændringer, så du kan gennemgå præcis, hvad der er ændret, før du committer eller henter opdateringer. Forgrenede arbejdsområder er tydeligere angivet i Fabric-brugerfladen, hvilket gør det lettere at identificere, hvilken gren hvert arbejdsområde er forbundet til.

Du kan finde flere oplysninger om Git-integrationsprocessen i følgende ressourcer.

• Hvad er Microsoft Fabric Git-integration?
• Grundlæggende begreber i Git-integration
• Kom i gang med Git-integration

Konfigurere en forbindelse til kildekontrolelementet

Du kan forbinde dit Fabric arbejdsområde til et Git-repository fra siden Workspace settings. Denne forbindelse lader dig committe og synkronisere ændringer direkte fra Fabric.

1. Se Kom i gang med Git-integration for detaljerede trin til at forbinde til et Git-repository i Azure DevOps eller GitHub.

2. Efter at have forbundet til Git-repositoryet, vises dine workspace-elementer, inklusive Fabric-dataagenter, i Source-kontrolpanelet. På statuslinjen nederst til venstre kan du se navnet på den tilsluttede gren, tidspunktet for den sidste synkronisering og Git-commit-id'et.

3. Det tilknyttede Git-repository viser en mappestruktur, der repræsenterer dine arbejdsområder, inklusive Fabric-dataagenter og deres konfigurationsfiler. Hver dataagent gemmes i sin egen mappe, så du kan gennemse ændringer, spore versionshistorik og bruge Git-arbejdsprocesser, f.eks. oprettelse af pullanmodninger til at flette opdateringer ind i din hovedgren.

4. Når du foretager ændringer i Fabric-dataagenten i et Git-forbundet arbejdsområde, opdages ændringerne, og dataagentens status i kildekontrolpanelet ændres til Uforpligtede ændringer. Disse ændringer kan omfatte:

   • Ændring af skemavalget.
   • Opdatering af AI-instruktioner eller datakildeinstruktioner.
   • Redigering af eksempelforespørgsler.
   • Udgivelse af dataagenten eller opdatering af dens udgivelsesbeskrivelse.

Enhver ændring – uanset om den er funktionel eller beskrivende – medfører, at dataagenten ikke synkroniseres med det sammenkædede Git-lager. Arbejdsområdeelementerne med ændringer vises under fanen Ændringer i ruden Kildekontrolelement. Du kan gennemse disse ændringer, sammenligne dem med den bekræftede version og bekræfte dem tilbage til Git-lageret for at synkronisere.

5. Når opdateringer foretages direkte i det linkede Git-repository (Azure DevOps eller GitHub), kan de inkludere handlinger som at ændre AI-instruktioner, ændre eksempelforespørgsler eller redigere publiceringsbeskrivelser. Du kan derefter bekræfte og skubbe disse ændringer til lageret. Når opdateringerne er sendt og tilgængelige i repositoryet, registrerer dit Fabric-arbejdsområde dem og viser en opdatering tilgængelig i versionskontrolpanelet. De opdaterede elementer, f.eks. dataagent, vises under fanen Opdateringer, hvor du kan gennemse og acceptere dem. Hvis du accepterer disse opdateringer, anvendes lagerændringerne på dine arbejdsområdeelementer, hvilket sikrer, at arbejdsområdet afspejler den seneste bekræftede version i Git.

Mappe- og filstruktur i Git-lageret

I det følgende gennemgår du strukturen for, hvordan en dataagents konfiguration gemmes i et Git-lager. Det er vigtigt at forstå denne struktur for at håndtere ændringer og følge bedste praksis. Når du bruger feature branches, foretag ændringer i den branch, der er knyttet til arbejdsområdet, gennemgå diffs i versionskontrolpanelet og merge via pull requests for kontrolleret promovering. Filerne og konfigurationsstrukturen for dataagenter forbliver den samme på tværs af grenene.

Rodstruktur

I roden gemmes dataagentens indhold under mappen filer . Inde i filer finder du en konfigurationsmappe , som indeholder data_agent.json, publish_info.json, kladdemappe og udgivet mappe.

I konfigurationsmappen indeholder publish_info.json udgivelsesbeskrivelsen for dataagenten. Denne fil kan opdateres for at ændre den beskrivelse, der vises, når dataagenten udgives.

Kladdemappen indeholder de konfigurationsfiler, der svarer til kladdeversionen af dataagenten, og den publicerede mappe indeholder konfigurationsfilerne for den publicerede version af dataagenten. Kladdemappen indeholder:

• Datakildemapper , hvor der er én mappe for hver datakilde, der bruges af dataagenten.
  • Datakilder til søhus eller lagersted: Mappenavne starter med lakehouse-tables- eller warehouse-tables-efterfulgt af navnet på søhuset eller lagerstedet.
  • Datakilder til semantiske modeller: Mappenavne starter med semantic-model-, efterfulgt af navnet på den semantiske model.
  • KQL-databasedatakilder: Mappenavne starter med kusto-, efterfulgt af navnet på KQL-databasen.
  • Ontologidatakilder: Mappenavne starter med ontology-, efterfulgt af ontologiens navn.

• stage_config.json , der indeholder aiInstructions, som refererer til agentinstruktionerne.

Hver datakildemappe indeholder datasource.json og fewshots.json. Men hvis datakilden er en semantisk model, understøtter den ikke eksempelforespørgsler, så dens mappe indeholder kun datasource.json.

datasource.json definerer konfigurationen for den pågældende datakilde, herunder:

• dataSourceInstructions, som repræsenterer instruktionerne for den pågældende datakilde.

• displayName, som viser navnet på datakilden.

• elements, som refererer til skematilknytningen og indeholder en komplet liste over tabeller og kolonner fra datakilden.

  • Hvert bord har en is_selected egenskab. Hvis true, er tabellen inkluderet, og hvis false, betyder det, at tabellen ikke er valgt og ikke vil blive brugt af dataagenten.
  • Kolonneposter vises is_selectedogså , men valg på kolonneniveau understøttes ikke i øjeblikket. Hvis en tabel er markeret, medtages alle dens kolonner uanset kolonneværdien is_selected . Hvis en tabel ikke er markeret (is_selected: false på tabelniveau), tages ingen af kolonnerne i betragtning, selvom den is_selected er angivet til true på kolonneniveau.

• Type konventioner:

  • Hvis typen er en datakilde, er det blot datakildetypen (f.eks.: "type": "lakehouse_tables").
  • Hvis typen er en tabel, slutter den med .table (f.eks.: "type": "lakehouse_tables.table").
  • Hvis typen er en kolonne, slutter den med .column (f.eks.: "type": "lakehouse_tables.column").

fewshots.json gemmer eksempelforespørgsler for datakilden. Hver post indeholder:

• id som det entydige id for eksempelforespørgslen.
• question, som henviser til spørgsmålet om naturligt sprog.
• query viser forespørgselsteksten, som kan være SQL eller KQL afhængigt af datakildetypen.

Den publicerede mappe afspejler strukturen i kladdemappen, men repræsenterer den publicerede version af dataagenten. Det er den bedste fremgangsmåde ikke at ændre filer i den publicerede mappe direkte. Ændringer skal foretages i kladdemappen. Når dataagenten er publiceret, afspejles disse ændringer i den publicerede mappe. Dette sikrer, at den publicerede version altid genereres fra en kontrolleret kladdetilstand.

Udrulningspipelines for dataagenter

Udrulningspipelines giver en kontrolleret måde at flytte dataagenter mellem arbejdsområder, der er knyttet til forskellige livscyklusfaser. Eksempel:

1. Udvikl en ny dataagent, eller opdater en eksisterende i udviklingsarbejdsområdet.
2. Hæv ændringerne af testarbejdsområdet til validering.
3. Hæv de testede ændringer til produktionsarbejdsområdet, hvor det er tilgængeligt for slutbrugerne.

Før du udrulter, skal du tildele et arbejdsområde til hver fase i udrulningspipelinen: udvikling, test og produktion. Hvis du ikke tildeler et arbejdsområde til test- eller produktionsfasen, oprettes arbejdsområderne automatisk. De automatisk oprettede arbejdsområder er opkaldt efter udviklingsarbejdsområdet med [test] eller [prod] tilføjet.

Sådan implementerer du ændringer:

• I pipelinen skal du gå til den fase, du vil udrulle fra (f.eks. udvikling).
• Vælg de elementer i det arbejdsområde, du vil installere.
• Vælg Installer for at hæve dem til næste fase.

Du kan gennemse en installationsplan, før du anvender ændringer, og sikre, at kun tilsigtede opdateringer fremhæves. Du kan få flere oplysninger under Kom i gang med udrulningspipelines.

Automate CI/CD with Azure DevOps Pipelines

Azure DevOps Pipelines-udvidelsen til Fabric tilbyder native opgaver, der kører Fabric CLI kommandoer i Azure DevOps pipeline-jobs. Teams kan orkestrere CI/CD for opdateringer af dataagenter ved hjælp af Azure DevOps (med CLI) sammen med eller i stedet for Fabric-deployeringspipelines. For at komme i gang skal du installere udvidelsen fra Visual Studio Marketplace, opsætte en serviceforbindelse i dit Azure DevOps-projekt, og tilføje Fabric CLI-opgaver til din pipeline-definition.

Massesynkronisering via batch-API'er (forhåndsvisning)

Import/Export Item Definitions Batch API'erne (forhåndsvisning) giver mulighed for storskala synkronisering af varedefinitioner, inklusive konfigurationer af dataagenter. Du kan eksportere og importere dataagentdefinitioner i batch for at effektivisere promoveringen på tværs af miljøer. For mere information, se dokumentationen Fabric REST API.

Publicér en Fabric-dataagent til deployment-pipelines

Publicering af en Fabric-dataagent gør den tilgængelig til brug på alle forskellige forbrugskanaler, herunder Copilot til Power BI, Microsoft Copilot Studio og Foundry Tools. Hvis du vil vurdere og bruge dataagenten på tværs af disse kanaler, skal dataagenten offentliggøres. Ikke-publicerede dataagenter er ikke tilgængelige til forbrug, selvom de er i produktionsarbejdsområdet. For at følge bedste praksis i overensstemmelse med udrulningspipelinen skal du være opmærksom på, at:

• Publicering fra et udviklingsarbejdsområde bør kun begrænses til autoriserede brugere, der arbejder med udvikling af dataagenter og ønsker at vurdere ydeevnen på tværs af forskellige forbrugskanaler. Adgangen til dette arbejdsområde skal begrænses, så ufærdige eller eksperimentelle dataagenter ikke vises for bredere målgrupper.
• Slutbrugere skal kun få adgang til dataagenter, der er publiceret fra produktionsarbejdsområdet, for at sikre, at de interagerer med stabile, godkendte versioner af dataagenten.

Denne tilgang understøtter både det funktionelle krav om at muliggøre forbrugs- og ydelsesevaluering, og den sikrer korrekt adgangskontrol ved at holde udviklings- og produktionsmiljøer adskilt.

Bedste praksis

• Brug en dedikeret gren til udviklingsarbejde på dataagenter, og flet til main efter kodegennemgang.
• Opbevar relaterede ressourcer (datakilder, dataagenter, notesbøger, pipelines) i det samme arbejdsområde for nemmere promovering.
• Test dataagenten ændres i testarbejdsområdet, før den opgraderes til produktion.
• Brug beskrivende commit-meddelelser for at gøre historikken lettere at forstå.
• Foretag ikke direkte ændringer i den publicerede mappe i Git-lageret.
• Brug miljø-agnostiske konfigurationsmønstre (for eksempel forbindelsesreferencer via Variable Library, hvor det understøttes) for at undgå hårdkodning af miljøspecifikke værdier i dataagent-datakildekonfigurationer. Denne praksis muliggør smidigere branch-sammenfletninger og implementeringer på tværs af udvikling, test og produktion.

Begrænsninger og overvejelser

• Det er kun arbejdsområder, der er forbundet til et Git-lager, der kan bruge Git-baserede ALM-funktioner.
• Serviceprincipper understøttes kun i Fabric-dataagenten som en del af ALM-scenarier. Hvis du har brug for at interagere med en dataagent uden for ALM-arbejdsprocesser, understøttes tjenesteprincipal ikke.
• Udrulningspipelines kræver, at kilde- og destinationsarbejdsområderne er i samme lejer.
• Et stort antal hyppige bekræftelser kan påvirke lagerets størrelse og ydeevne.

Relateret indhold

• Kom i gang med Git-integration
• Grundlæggende begreber i Git-integration
• Hvad er livscyklusstyring i Microsoft Fabric?