Källkontroll, CI/CD och ALM för Fabric dataagent

Den här artikeln beskriver hur du hanterar Fabric dataagenter med hjälp av Git-integrerings- och distributionspipelines som en del av Microsoft Fabric 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ällkontroll för Fabric-dataagenter är för tillfället i förhandsvisning.

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.

De här funktionerna ger tillsammans stöd för ALM från slutpunkt till slutpunkt för Fabric dataagenter.

Förutsättningar

• En betald F2 eller högre Fabric Kapacitet, eller en Power BI Premium kapacitet per kapacitet (P1 eller högre) med Microsoft Fabric Aktiverat.
• Aktivera kors-geo-bearbetning och kors-geo-lagring för AI baserat på krav som beskrivs i klientinställningarna för Fabricdataagenten.
• Minst en av dessa datakällor, med data: Ett lager, ett sjöhus, en Power BI-semantisk modell, en KQL-databas, en speglad databas eller en ontologi. Du måste ha läsbehörighet till datakällan.

Git-integrering

Microsoft Fabric Git-integrering synkroniserar en Fabric arbetsyta med en Git-lagringsplats så att du kan använda dina befintliga utvecklingsprocesser, verktyg och metodtips direkt på Fabric-plattformen. Den stöder Azure DevOps och GitHub och är tillgänglig på arbetsytenivå. När du kommitterar ändringar från Fabric, inklusive uppdateringar av dataagentkonfigurationen, sparas dessa ändringar som filer i den anslutna Git-lagringsplatsen. 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)

Senaste förbättringarna för Git-integrering

Fabric Git-integrering stöder nu selektiv förgrening, så att du kan växla den anslutna grenen på arbetsytans nivå så att den överensstämmer med arbetsflöden för funktionsgrenar. Fönstret Källkontroll ger också en inbyggd diff-upplevelse för objektändringar, så att du kan granska exakt vad som har ändrats innan du genomför eller hämtar uppdateringar. Förgrenade arbetsytor anges tydligare i Fabric användargränssnitt, vilket gör det enklare att identifiera vilken gren varje arbetsyta är ansluten till.

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

• Vad är Microsoft Fabric Git-integrering?
• Grundläggande begrepp i Git-integration
• Kom igång med Git-integration

Konfigurera en anslutning till källkontrollen

Du kan ansluta din Fabric-arbetsyta till en Git-lagringsplats från sidan Arbetsyta. Den här anslutningen låter dig komma åt och synkronisera ändringar direkt från Fabric.

1. Mer information om hur du ansluter till en Git-lagringsplats i Azure DevOps eller GitHub finns i Get started with Git integration .

2. När du har anslutit till Git-lagringsplatsen visas dina arbetsyteobjekt, inklusive Fabric dataagenter, 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.

3. Den länkade Git-lagringsplatsen visar en mappstruktur som representerar dina arbetsyteobjekt, inklusive Fabric dataagenter 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.

4. 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.

5. 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 i lagringsplatsen, identifierar din Fabric-arbetsyta dem och visar en notifikation 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. När du använder funktionsgrenar gör du ändringar i grenen som är kopplad till arbetsytan, granskar ändringar i fönstret Källkontroll och sammanfogar via pull-förfrågningar för kontrollerad befordran. Filerna och konfigurationsstrukturen för dataagenter förblir desamma mellan grenar.

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. Varje mappnamn börjar med ett prefix som identifierar datakällans typ, följt av namnet på datakällan. Till exempel:

  • 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.
  • Ontologidatakällor: Mappnamn börjar med ontology-, följt av namnet på ontologin.

  Andra stödda datakällor, såsom SQL-databas i Fabric, speglade databaser, grafmodeller och Azure AI-sökning, följer samma namngivningsmönster. För hela listan över stödda datakällor, se Lägg till och konfigurera datakällor i Fabric data agent.

• 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 inte för närvarande. 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, vilket syftar på 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:

1. Utveckla en ny dataagent eller uppdatera en befintlig i utvecklingsarbetsytan.
2. Flytta upp ändringarna till testarbetsytan för validering.
3. 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.

Automatisera CI/CD med Azure DevOps Pipelines

Tillägget Azure DevOps Pipelines för Fabric erbjuder inbyggda funktioner som kör Fabric CLI-kommandon i Azure DevOps pipelinejobb. Teams kan samordna CI/CD för dataagentuppdateringar med hjälp av Azure DevOps (med CLI) tillsammans med eller i stället för Fabric distributionspipelines. Kom igång genom att installera tillägget från Visual Studio Marketplace, konfigurera en tjänstanslutning i ditt Azure DevOps-projekt och lägga till Fabric CLI-uppgifter i pipelinedefinitionen.

Masssynkronisering via batch-API:er (förhandsversion)

Batch-API:er för import/exportobjekt (förhandsversion) ger ett alternativ för storskalig synkronisering av objektdefinitioner, inklusive konfigurationer av dataagenter. Du kan exportera och importera dataagentdefinitioner i batch för att effektivisera befordran mellan miljöer. Mer information finns i dokumentationen Fabric REST API.

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 Foundry Tools. 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.
• Använd miljöagnostiska konfigurationsmönster (till exempel anslutningsreferenser via variabelbibliotek där det stöds) för att undvika hårdkodning av miljöspecifika värden i dataagentens datakällans konfigurationer. Den här metoden underlättar smidigare grensammanslagningar och distributioner i utveckling, testning och produktion.

Begränsningar och överväganden

• Endast arbetsytor som är anslutna till en Git-lagringsplats kan använda Git-baserade ALM-funktioner.
• Service Principals stöds endast i Fabric dataprosessorn som en del av 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.

Relaterat innehåll

• Kom igång med Git-integration
• Grundläggande begrepp i Git-integration
• Vad är livscykelhantering i Microsoft Fabric?