Källkontroll, CI/CD och ALM för Fabric-dataagenten (förhandsversion)

Den här artikeln beskriver hur du hanterar Infrastrukturdataagenter med hjälp av Git-integrerings- och distributionspipelines som en del av Microsoft Fabrics alm-funktioner (Application Lifecycle Management). Du lär dig hur du ansluter en arbetsyta till en Git-lagringsplats. Du får också lära dig hur du spårar och versionshanterar dataagentkonfigurationer. Slutligen får du lära dig hur du höjer upp uppdateringar i utvecklings-, test- och produktionsmiljöer. Git-integrerings- och distributionspipelines möjliggör kontinuerlig integrering och kontinuerlig distribution (CI/CD) av dataagentändringar, vilket gör att uppdateringar kan testas och höjas upp automatiskt som en del av ditt ALM-arbetsflöde. Källkontrollen för Fabric-dataagenter är för närvarande i förhandsversion.

Du kan använda två kompletterande metoder för att stödja ALM för Fabric-dataagenter:

Git-integrering: Synkronisera en hel arbetsyta med en Git-lagringsplats (antingen Azure DevOps eller GitHub som Git-provider) för att aktivera versionskontroll, samarbete via grenar och historikspårning för enskilda objekt, inklusive Fabric-dataagenter.
Distributionspipelines: Höj upp innehåll mellan separata arbetsytor som representerar utvecklings-, test- och produktionsfaser med hjälp av inbyggda pipelines.

Dessa funktioner tillsammans erbjuder komplett ALM-stöd för Fabric-dataagenter.

Viktigt!

Den här funktionen är i förhandsversion.

Förutsättningar

En betald F2- eller högre Infrastrukturkapacitet, eller en Power BI Premium per kapacitet (P1 eller högre) kapacitet med Microsoft Fabric aktiverat
Klientinställningarna för infrastrukturdataagenten är aktiverade.
Cross-geo-bearbetning för AI är aktiverad.
Lagring mellan geografiska områden för AI- är aktiverat.
Minst en av dessa: ett lager, ett sjöhus, en eller flera Power BI-semantiska modeller eller en KQL-databas med data.
Power BI-semantiska modeller via XMLA-slutpunktsklientväxeln är aktiverad för Power BI-semantiska modelldatakällor.

Git-integrering

Microsoft Fabric Git-integrering synkroniserar en Infrastruktur-arbetsyta med en Git-lagringsplats så att du kan använda dina befintliga utvecklingsprocesser, verktyg och metodtips direkt i Fabric-plattformen. Det stöder Azure DevOps och GitHub och är tillgängligt på arbetsytenivå. När du checkar in ändringar från Fabric, inklusive uppdateringar av konfigurationen av dataagenten, sparas dessa ändringar som filer i det anslutna Git-repositoryt. Dess viktigaste funktioner är:

Fullständig säkerhetskopiering och versionskontroll av arbetsyteobjekt
Mappstrukturen i Git speglar arbetsytans struktur
Dataagentkonfigurationer (schemaval, AI-instruktioner, datakällsinstruktioner, exempelfrågor) lagras i strukturerade filer i dedikerade mappar
Möjlighet att visa skillnader, granska historik och återgå till tidigare tillstånd via historik för olika arbetsyteobjekt, inklusive dataagenter
Grenbaserat samarbete (funktionsgrenar, huvud)

Mer information om Git-integreringsprocessen finns i följande resurser.

Konfigurera en anslutning till källkontrollen

Du kan ansluta din Fabric-arbetsyta till ett Git-förråd från sidan Inställningar för arbetsyta. Med den här anslutningen kan du kommitta och synkronisera ändringar direkt från Fabric.

Mer information om hur du ansluter till en Git-lagringsplats i Azure DevOps eller GitHub finns i Komma igång med Git-integrering .
När du har anslutit till Git-lagringsplatsen visas dina arbetsyteobjekt, inklusive Infrastrukturdataagenter, på kontrollpanelen Källa. I statusfältet längst ned till vänster kan du se namnet på den anslutna grenen, tidpunkten för den senaste synkroniseringen och Git-inchecknings-ID:t.

Den länkade Git-lagringsplatsen visar en mappstruktur som representerar dina arbetsyteobjekt, inklusive Infrastrukturdataagenter och deras konfigurationsfiler. Varje dataagent lagras i sin egen mapp, så att du kan granska ändringar, spåra versionshistorik och använda Git-arbetsflöden som att skapa pull-begäranden för att koppla uppdateringar till din huvudgren.

När du gör ändringar i Fabric-dataagenten på en Git-ansluten arbetsyta identifieras ändringarna och dataagentens status i fönstret Källkontroll ändras till Ej tillåtna ändringar. Dessa ändringar kan omfatta:
- Ändra schemasvalet.
- Uppdatera AI-instruktioner eller instruktioner för datakällor.
- Redigera exempelfrågor.
- Publicera dataagenten eller uppdatera dess publiceringsbeskrivning.

Alla ändringar – oavsett om de är funktionella eller beskrivande – gör att dataagenten blir osynkroniserad med den länkade Git-lagringsplatsen. Arbetsyteobjekten med ändringar visas under fliken Ändringar i fönstret Källkontroll. Du kan granska dessa ändringar, jämföra dem med den bekräftade versionen och checka in dem på Git-lagringsplatsen för att synkronisera dem.

När uppdateringar görs direkt på den länkade Git-lagringsplatsen (Azure DevOps eller GitHub) kan de innehålla åtgärder som att ändra AI-instruktioner, ändra exempelfrågor eller redigera publiceringsbeskrivningar. Du kan sedan kommittera och pusha dessa ändringar till lagringsplatsen. När uppdateringarna har pushats och är tillgängliga på lagringsplatsen, identifierar din Fabric-arbetsyta dem och visar ett meddelande om tillgängliga uppdateringar i panelen Källkontroll. De uppdaterade objekten, till exempel dataagenten, visas under fliken Uppdateringar, där du kan granska och acceptera dem. Om du accepterar dessa uppdateringar tillämpas lagringsplatsens ändringar på dina arbetsyteobjekt, vilket säkerställer att arbetsytan återspeglar den senaste bekräftade versionen i Git.

Mapp- och filstruktur på Git-lagringsplatsen

I följande avsnitt granskar du strukturen för hur en dataagents konfiguration lagras på en Git-lagringsplats. Att förstå den här strukturen är viktigt för att hantera ändringar och följa bästa praxis.

Rotstruktur

I roten lagras innehållet för dataagenten under mappen 'filer'. I filer hittar du en konfigurationsmapp som innehåller data_agent.json, publish_info.json, utkastmapp och publicerad mapp.

I mappen config innehåller publish_info.json publiceringsbeskrivningen för dataagenten. Den här filen kan uppdateras för att ändra beskrivningen som visas när dataagenten publiceras.

Utkastmappen innehåller de konfigurationsfiler som motsvarar utkastversionen av dataagenten och den publicerade mappen innehåller konfigurationsfilerna för den publicerade versionen av dataagenten. Utkastmappen innehåller:

Datakällans mappar där det finns en mapp för varje datakälla som används av dataagenten.
- Datakällor för Lakehouse eller lager: Mappnamn börjar med lakehouse-tables- eller warehouse-tables-, följt av namnet på lakehouse eller lagret.
- Semantiska modelldatakällor: Mappnamn börjar med semantic-model-, följt av namnet på den semantiska modellen.
- KQL-databasdatakällor: Mappnamn börjar med kusto-, följt av namnet på KQL-databasen.

stage_config.json som innehåller aiInstructions, som refererar till agentinstruktionerna.

Varje datakällamapp innehåller datasource.json och fewshots.json. Men om datakällan är en semantisk modell stöder den inte exempelfrågor, så dess mapp innehåller bara datasource.json.

datasource.json definierar konfigurationen för datakällan, inklusive:

dataSourceInstructions, som representerar instruktionerna för datakällan.
displayName, som visar namnet på datakällan.
elements, som refererar till schemakartan och innehåller en fullständig lista över tabeller och kolumner från datakällan.
- Varje tabell har en is_selected egenskap. Om true, inkluderas tabellen och om falseinnebär det att tabellen inte är markerad och inte används av dataagenten.
- Kolumnposter visar också is_selected, men val på kolumnnivå stöds för närvarande inte. Om en tabell är markerad inkluderas alla dess kolumner oavsett kolumnvärde is_selected . Om en tabell inte är markerad (is_selected: false på tabellnivå) beaktas ingen av kolumnerna trots att is_selected är inställd till true på kolumnnivå.
Typkonventioner:
- Om typen är en datakälla är det bara datakälltypen (till exempel: "type": "lakehouse_tables").
- Om typen är en tabell slutar den med .table (till exempel: "type": "lakehouse_tables.table").
- Om typen är en kolumn slutar den med .column (till exempel: "type": "lakehouse_tables.column").

fewshots.json lagrar exempelfrågor för datakällan. Varje post innehåller:

id som unik identifierare för exempelfrågan.
question, som refererar till frågan om naturligt språk.
query visar frågetexten, som kan vara SQL eller KQL beroende på datakälltypen.

Den publicerade mappen speglar strukturen i utkastmappen, men representerar den publicerade versionen av dataagenten. Det är bästa praxis att inte ändra filer i den publicerade mappen direkt. Ändringar bör göras i utkastmappen. När dataagenten har publicerats återspeglas dessa ändringar i den publicerade mappen. Detta säkerställer att den publicerade versionen alltid genereras från ett kontrollerat utkasttillstånd.

Distributionspipelines för dataagenter

Distributionspipelines är ett kontrollerat sätt att flytta dataagenter mellan arbetsytor som mappats till olika livscykelsteg. Till exempel:

Utveckla en ny dataagent eller uppdatera en befintlig i utvecklingsarbetsytan.
Flytta upp ändringarna till testarbetsytan för validering.
Höj upp de testade ändringarna till produktionsarbetsytan där de är tillgängliga för slutanvändare.

Innan du distribuerar måste du tilldela en arbetsyta till varje steg i distributionspipelinen: utveckling, test och produktion. Om du inte tilldelar en arbetsyta till test- eller produktionsfasen skapas arbetsytorna automatiskt. De automatiskt skapade arbetsytorna namnges efter utvecklingsarbetsytan, med [test] eller [prod] tillagt.

Så här distribuerar du ändringar:

I pipelinen går du till den fas som du vill distribuera från (till exempel utveckling).
Välj de objekt på arbetsytan som du vill distribuera.
Välj Distribuera för att flytta upp dem till nästa steg.

Du kan granska en distributionsplan innan du tillämpar ändringar, vilket säkerställer att endast avsedda uppdateringar främjas. För mer information, se Kom igång med distributionspipelines.

Anmärkning

Tjänstprincipaler stöds endast i Fabric-data-agenten som en del av ALM-scenarier. Det här stödet är begränsat till att aktivera ALM-åtgärder (till exempel Git-integrerings- och distributionspipelines) och omfattar inte andra funktioner för Fabric-dataagenter. Om du behöver interagera med en dataagent utanför ALM-arbetsflöden stöds inte service principal.

Publicera en Fabric dataagent för distributionspipelines

Genom att publicera en Fabric-dataagent blir den tillgänglig för användning i alla olika förbrukningskanaler, inklusive Copilot för Power BI, Microsoft Copilot Studio och Azure AI Foundry Services. För att kunna utvärdera och använda dataagenten i dessa kanaler måste dataagenten publiceras. opublicerade dataagenter är inte tillgängliga för förbrukning även om de finns i produktionsarbetsytan. Observera att för att följa bästa praxis i enlighet med distributionsrörledningen:

Publicering från en utvecklingsarbetsyta bör begränsas till behöriga användare som endast arbetar med utveckling av dataagenter och som vill utvärdera dess prestanda i olika förbrukningskanaler. Åtkomsten till den här arbetsytan måste begränsas så att oavslutade eller experimentella dataagenter inte exponeras för bredare målgrupper.
Slutanvändarna bör endast komma åt dataagenter som publiceras från produktionsarbetsytan, vilket säkerställer att de interagerar med stabila, godkända versioner av dataagenten.

Den här metoden stöder både funktionskravet för att aktivera förbrukning och prestandautvärdering och säkerställer korrekt åtkomstkontroll genom att hålla utvecklings- och produktionsmiljöer åtskilda.

Metodtips

Använd en särskild gren för utvecklingsarbete på dataagenter och slå ihop den med main efter kodgranskning.
Behåll relaterade resurser (datakällor, dataagenter, notebook-filer, pipelines) på samma arbetsyta för enklare befordran.
Testa data-agentändringar i testarbetsytan innan du flyttar till produktion.
Använd beskrivande incheckningsmeddelanden för att göra historiken enklare att förstå.
Gör inte ändringar direkt i den publicerade mappen på Git-lagringsplatsen.

Begränsningar och överväganden

Endast arbetsytor som är anslutna till en Git-lagringsplats kan använda Git-baserade ALM-funktioner.
Tjänsteprincipaler stöds endast i Fabric-dataagenten inom ALM-scenarier. Om du behöver interagera med en dataagent utanför ALM-arbetsflöden stöds inte service principal.
Distributionspipelines kräver att käll- och målarbetsytorna finns i samma klientorganisation.
Ett stort antal frekventa commits kan påverka repositoriets storlek och prestanda.

Feedback

Var den här sidan till hjälp?

Last updated on 2025-10-04