Broncodebeheer, CI/CD en ALM voor Fabric gegevensagent

In dit artikel wordt beschreven hoe u Fabric gegevensagenten beheert met behulp van Git-integratie- en implementatiepijplijnen als onderdeel van de mogelijkheden van Microsoft Fabric Application Lifecycle Management (ALM). U leert hoe u een werkruimte verbindt met een Git-opslagplaats. U leert ook hoe u configuraties van gegevensagents bijhoudt en versiet. Ten slotte leert u hoe u updates promoveert in ontwikkel-, test- en productieomgevingen. Git-integratie- en implementatiepijplijnen maken continue integratie en continue implementatie (CI/CD) van gegevensagentwijzigingen mogelijk, zodat updates automatisch kunnen worden getest en gepromoveerd als onderdeel van uw ALM-werkstroom. Broncodebeheer voor Fabric gegevensagenten is momenteel beschikbaar als preview-versie.

U kunt twee aanvullende methoden gebruiken om ALM te ondersteunen voor Fabric gegevensagenten:

Git-integratie: Synchroniseer een hele werkruimte met een Git-opslagplaats (Azure DevOps of GitHub als Git-provider) om versiebeheer, samenwerking via vertakkingen en geschiedenistracering voor afzonderlijke items, waaronder Fabric gegevensagenten, mogelijk te maken.
Implementatiepijplijnen: promoot inhoud tussen afzonderlijke werkruimten die ontwikkelings-, test- en productiefasen vertegenwoordigen met behulp van ingebouwde pijplijnen.

Deze mogelijkheden bieden samen end-to-end ALM-ondersteuning voor Fabric gegevensagenten.

Vereiste voorwaarden

Een betaalde Fabric-capaciteit van F2 of hoger of een Power BI Premium-capaciteit van P1 of hoger waarin Microsoft Fabric is ingeschakeld.
Schakel cross-geo-verwerking en cross-geo-opslag voor AI in op basis van vereisten die worden uitgelegd in tenantinstellingen van de Fabric-gegevensagent.
Ten minste één van deze gegevensbronnen, met gegevens: Een magazijn, een lakehouse, een semantisch Power BI-model, een KQL-database, een gespiegelde database of een ontologie. U moet leestoegang hebben tot de gegevensbron.

Git-integratie

Microsoft Fabric Git-integratie synchroniseert een Fabric werkruimte met een Git-opslagplaats, zodat u uw bestaande ontwikkelprocessen, hulpprogramma's en best practices rechtstreeks in het Fabric platform kunt gebruiken. Het ondersteunt Azure DevOps en GitHub en is beschikbaar op werkruimteniveau. Wanneer u wijzigingen doorvoert van Fabric, inclusief updates voor de configuratie van de gegevensagent, worden deze wijzigingen opgeslagen als bestanden in de verbonden Git-opslagplaats. De belangrijkste mogelijkheden zijn:

Volledige back-up en versiebeheer van werkruimte-items
De mapstructuur in Git spiegelt de werkruimtestructuur
Configuraties van gegevensagenten (schemaselectie, AI-instructies, instructies voor gegevensbronnen, voorbeeldquery's) worden opgeslagen in gestructureerde bestanden in toegewezen mappen
Mogelijkheid om verschillen te bekijken, geschiedenis te controleren en terug te keren naar eerdere statussen via geschiedenis voor verschillende werkruimte-items, waaronder gegevensagenten
Samenwerking op basis van vertakkingen (functievertakkingen, hoofd)

Nieuwste verbeteringen in Git-integratie

Fabric Git-integratie ondersteunt nu selectief brancheren, zodat u de verbonden branch op werkruimteniveau kunt wisselen om aan te sluiten bij werkstromen voor featurebranches. Het deelvenster Broncodebeheer biedt ook een ingebouwde diff-ervaring voor itemwijzigingen, zodat u precies kunt bekijken wat er is gewijzigd voordat u updates doorvoert of ophaalt. Vertakkingswerkruimten worden duidelijker aangegeven in de gebruikersinterface van Fabric, zodat u gemakkelijker kunt bepalen met welke vertakking elke werkruimte is verbonden.

Raadpleeg de volgende bronnen voor meer informatie over het Git-integratieproces.

Een verbinding met broncodebeheer instellen

U kunt uw Fabric werkruimte verbinden met een Git-opslagplaats vanaf de pagina Werkruimteinstellingen. Met deze verbinding kunt u wijzigingen rechtstreeks vanuit Fabric doorvoeren en synchroniseren.

Zie Get gestart met Git-integratie voor gedetailleerde stappen om verbinding te maken met een Git-opslagplaats in Azure DevOps of GitHub.
Nadat u verbinding hebt gemaakt met de Git-opslagplaats, worden uw werkruimte-items, waaronder Fabric gegevensagenten, weergegeven in het configuratiescherm Bron. In de statusbalk linksonder ziet u de naam van de verbonden vertakking, het tijdstip van de laatste synchronisatie en de Git-doorvoer-id.

In de gekoppelde Git-opslagplaats wordt een mapstructuur weergegeven die uw werkruimte-items vertegenwoordigt, waaronder Fabric gegevensagenten en de bijbehorende configuratiebestanden. Elke gegevensagent wordt opgeslagen in een eigen map, zodat u wijzigingen kunt controleren, versiegeschiedenis kunt bijhouden en Git-werkstromen kunt gebruiken, zoals het maken van pull-aanvragen om updates samen te voegen in uw hoofdvertakking.

Wanneer u wijzigingen aanbrengt in de Fabric gegevensagent in een met Git verbonden werkruimte, worden de wijzigingen gedetecteerd en verandert de status van de gegevensagent in het deelvenster Broncodebeheer in Niet-doorgevoerde wijzigingen. Deze wijzigingen kunnen het volgende omvatten:
- De schemaselectie wijzigen.
- AI-instructies of instructies voor gegevensbronnen bijwerken.
- Voorbeeldqueries bewerken.
- De gegevensagent publiceren of de publicatiebeschrijving bijwerken.

Elke wijziging, ongeacht of deze functioneel of beschrijvend is, zorgt ervoor dat de gegevensagent niet meer wordt gesynchroniseerd met de gekoppelde Git-opslagplaats. De werkruimte-items met wijzigingen worden weergegeven op het tabblad Wijzigingen in het deelvenster Broncodebeheer. U kunt deze wijzigingen bekijken, vergelijken met de doorgevoerde versie en deze doorvoeren naar de Git-opslagplaats om te synchroniseren.

Wanneer updates rechtstreeks worden doorgevoerd in de gekoppelde Git-opslagplaats (Azure DevOps of GitHub), kunnen ze acties bevatten, zoals het wijzigen van AI-instructies, het wijzigen van voorbeeldquery's of het bewerken van publicatiebeschrijvingen. Vervolgens kunt u deze wijzigingen committen en pushen naar de opslagplaats. Zodra de updates zijn gepusht en beschikbaar zijn in de opslagplaats, detecteert uw Fabric-werkruimte deze en verschijnt er een melding in het deelvenster Broncodebeheer dat er updates beschikbaar zijn. De bijgewerkte items, zoals gegevensagent, worden weergegeven op het tabblad Updates, waar u ze kunt bekijken en accepteren. Als u deze updates accepteert, worden de wijzigingen in de opslagplaats toegepast op uw werkruimte-items, zodat de werkruimte de meest recente doorgevoerde versie in Git weerspiegelt.

Map- en bestandsstructuur in de Git-opslagplaats

In het volgende bekijkt u de structuur van de wijze waarop de configuratie van een gegevensagent wordt opgeslagen in een Git-opslagplaats. Inzicht in deze structuur is belangrijk voor het beheren van wijzigingen en het volgen van aanbevolen procedures. Wanneer u feature branches gebruikt, brengt u wijzigingen aan in de branch die is gekoppeld aan de werkruimte, bekijkt u de verschillen in het deelvenster Broncodebeheer en voegt u samen via pull requests voor gecontroleerde promotie. De bestanden en configuratiestructuur voor gegevensagenten blijven hetzelfde in verschillende vertakkingen.

Hoofdstructuur

De inhoud van de gegevensagent wordt opgeslagen in de map bestanden op de root. In bestanden vindt u een configuratiemap, die data_agent.json, publish_info.json, conceptmap en gepubliceerde map bevat.

In de configuratiemap bevat de publish_info.json de publicatiebeschrijving voor de gegevensagent. Dit bestand kan worden bijgewerkt om de beschrijving te wijzigen die wordt weergegeven wanneer de gegevensagent wordt gepubliceerd.

De conceptmap bevat de configuratiebestanden die overeenkomen met de conceptversie van de gegevensagent en de gepubliceerde map bevat de configuratiebestanden voor de gepubliceerde versie van de gegevensagent. De conceptmap bevat:

Mappen met gegevensbronnen waarbij er één map is voor elke gegevensbron die door de gegevensagent wordt gebruikt. Elke mapnaam begint met een voorvoegsel dat het type gegevensbron identificeert, gevolgd door de naam van de gegevensbron. Voorbeeld:
- Lakehouse- of magazijngegevensbronnen: mapnamen beginnen met lakehouse-tables- of warehouse-tables-, gevolgd door de naam van het lakehouse of magazijn.
- Semantische modelgegevensbronnen: Mapnamen beginnen met semantic-model-, gevolgd door de naam van het semantische model.
- KQL-databasegegevensbronnen: Mapnamen beginnen met kusto-, gevolgd door de naam van de KQL-database.
- Ontologiegegevensbronnen: mapnamen beginnen met ontology-, gevolgd door de naam van de ontologie.
Andere ondersteunde databronnen, zoals SQL-database in Fabric, gespiegelde databases, grafmodellen en Azure AI Zoeken, volgen hetzelfde naampatroon. Voor de volledige lijst van ondersteunde databronnen, zie Voeg toe en configureer databronnen in Fabric data agent.

stage_config.json die de instructies van de agent bevat aiInstructions.

Elke gegevensbronmap bevat datasource.json en fewshots.json. Als de gegevensbron echter een semantisch model is, biedt deze geen ondersteuning voor voorbeeldquery's, zodat de map alleen datasource.jsonbevat.

De datasource.json definieert de configuratie voor die gegevensbron, waaronder:

dataSourceInstructions, dat de instructies voor die gegevensbron vertegenwoordigt.
displayName, waarin de naam van de gegevensbron wordt weergegeven.
elements, die verwijst naar de schemastructuur en een volledige lijst van tabellen en kolommen uit de databron bevat.
- Elke tabel heeft een is_selected eigenschap. Als true, de tabel is opgenomen en als false, betekent dit dat de tabel niet is geselecteerd en niet wordt gebruikt door de gegevensagent.
- Kolomvermeldingen worden ook weergegeven is_selected, maar selectie op kolomniveau wordt momenteel niet ondersteund. Als een tabel is geselecteerd, worden alle kolommen ervan opgenomen, ongeacht de kolomwaarde is_selected . Als een tabel niet is geselecteerd (is_selected: false op het tabelniveau), worden geen van de kolommen beschouwd, zelfs niet wanneer is_selected is ingesteld op true op kolomniveau.
Typeconventies:
- Als het type een gegevensbron is, is dit gewoon het gegevensbrontype (bijvoorbeeld: "type": "lakehouse_tables").
- Als het type een tabel is, eindigt dit op .table (bijvoorbeeld: "type": "lakehouse_tables.table").
- Als het type een kolom is, eindigt dit op .column (bijvoorbeeld: "type": "lakehouse_tables.column").

In het fewshots.json worden voorbeeldquery's voor de gegevensbron opgeslagen. Elke vermelding omvat:

id als de unieke id voor de voorbeeldquery.
question, wat verwijst naar de natuurlijke taalvraag.
query geeft de querytekst weer. Dit kan SQL of KQL zijn, afhankelijk van het gegevensbrontype.

De gepubliceerde map weerspiegelt de structuur van de conceptmap, maar vertegenwoordigt de gepubliceerde versie van de gegevensagent. Het is raadzaam om bestanden in de gepubliceerde map niet rechtstreeks te wijzigen. Wijzigingen moeten worden aangebracht in de conceptmap. Zodra de gegevensagent is gepubliceerd, worden deze wijzigingen doorgevoerd in de gepubliceerde map. Dit zorgt ervoor dat de gepubliceerde versie altijd wordt gegenereerd op basis van een gecontroleerde conceptstatus.

Implementatiepijplijnen voor gegevensagents

Implementatiepijplijnen bieden een gecontroleerde manier om gegevensagents te verplaatsen tussen werkruimten die zijn toegewezen aan verschillende levenscyclusfasen. Voorbeeld:

Ontwikkel een nieuwe gegevensagent of werk een bestaande gegevensagent bij in de ontwikkelwerkruimte.
Promoot de wijzigingen in de testwerkruimte voor validatie.
Promoot de geteste wijzigingen in de productiewerkruimte waar deze beschikbaar is voor eindgebruikers.

Voordat u implementeert, moet u een werkruimte toewijzen aan elke fase in de implementatiepijplijn: ontwikkeling, test en productie. Als u geen werkruimte toewijst aan de test- of productiefase, worden de werkruimten automatisch gemaakt. De automatisch gemaakte werkruimten worden vernoemd naar de ontwikkelwerkruimte, waarbij [test] of [prod] is toegevoegd.

Om wijzigingen uit te rollen:

Ga in de pijplijn naar de fase waaruit u wilt implementeren (bijvoorbeeld ontwikkeling).
Selecteer de items in de werkruimte die u wilt implementeren.
Selecteer Implementeren om deze te promoveren naar de volgende fase.

U kunt een implementatieplan controleren voordat u wijzigingen toepast, zodat alleen de beoogde updates worden gepromoveerd. Zie Aan de slag met implementatiepijplijnen voor meer informatie.

CI/CD automatiseren met Azure DevOps-pijplijnen

De Azure DevOps Pipelines-extensie voor Fabric bevat systeemeigen taken die Fabric CLI opdrachten uitvoeren in Azure DevOps pijplijntaken. Teams kunnen CI/CD orkestreren voor het bijwerken van gegevensagenten met behulp van Azure DevOps (met de CLI), naast of in plaats van Fabric-implementatiepijplijnen. Als u wilt beginnen, installeert u de extensie vanuit de Visual Studio Marketplace, stelt u een serviceverbinding in uw Azure DevOps project in en voegt u Fabric CLI-taken toe aan uw pijplijndefinitie.

Synchronisatie in bulk via batch-API's (preview)

De Batch-API's voor import/exportitems (preview) bieden een optie voor grootschalige synchronisatie van itemdefinities, waaronder configuraties van gegevensagenten. U kunt definities van gegevensagenten in batch exporteren en importeren om promotie in omgevingen te stroomlijnen. Zie de documentatie Fabric REST API voor meer informatie.

Opmerking

Service-principals worden alleen ondersteund in de Fabric data-agent als onderdeel van ALM-scenario's. Deze ondersteuning is beperkt tot het inschakelen van ALM-bewerkingen (zoals Git-integratie- en implementatiepijplijnen) en wordt niet uitgebreid naar andere Fabric functies van de gegevensagent. Als u wilt communiceren met een gegevensagent buiten ALM-werkstromen, wordt de service-principal niet ondersteund.

Een Fabric-gegevensagent publiceren voor de implementatiepijplijnen

Als u een Fabric-gegevensagent publiceert, is deze beschikbaar voor gebruik in alle verschillende verbruikskanalen, waaronder Copilot voor Power BI, Microsoft Copilot Studio en Foundry Tools. Als u de gegevensagent in deze kanalen wilt evalueren en gebruiken, moet de gegevensagent worden gepubliceerd; niet-gepubliceerde gegevensagents zijn niet toegankelijk voor verbruik, zelfs niet als ze zich in de productiewerkruimte bevinden. Als u de aanbevolen procedures in overeenstemming met de implementatiepijplijn wilt volgen, moet u er rekening mee houden dat:

Publiceren vanuit een ontwikkelwerkruimte moet worden beperkt tot geautoriseerde gebruikers die alleen aan de ontwikkeling van gegevensagenten werken en de prestaties in verschillende verbruikskanalen willen beoordelen. De toegang tot deze werkruimte moet worden beperkt, zodat niet-voltooide of experimentele gegevensagenten niet worden blootgesteld aan bredere doelgroepen.
Eindgebruikers moeten alleen toegang hebben tot gegevensagenten die zijn gepubliceerd vanuit de productiewerkruimte, zodat ze communiceren met stabiele, goedgekeurde versies van de gegevensagent.

Deze aanpak ondersteunt zowel de functionele vereiste voor het inschakelen van verbruik en prestatie-evaluatie en zorgt voor een goed toegangsbeheer door ontwikkel- en productieomgevingen gescheiden te houden.

Beste praktijken

Gebruik een aparte branche voor ontwikkelingswerk aan data-agenten en voeg deze samen naar de hoofdbranch na de codebeoordeling.
Bewaar gerelateerde resources (gegevensbronnen, gegevensagenten, notebooks, pijplijnen) in dezelfde werkruimte voor eenvoudigere promotie.
Test wijzigingen in de gegevensagent in de testwerkruimte voordat u naar productie gaat.
Gebruik beschrijvende doorvoerberichten om de geschiedenis gemakkelijker te begrijpen.
Breng niet rechtstreeks wijzigingen aan in de gepubliceerde map in de Git-opslagplaats.
Gebruik omgevingsagnostische configuratiepatronen (bijvoorbeeld verbindingsverwijzingen via de Variabele Bibliotheek waar dit wordt ondersteund) om te voorkomen dat er omgevingsspecifieke waarden in de configuraties van gegevensbron van gegevensagenten worden hardcoded. Deze procedure vereenvoudigt soepelere vertakkingssamenvoegingen en implementaties in ontwikkeling, test en productie.

Beperkingen en overwegingen

Alleen werkruimten die zijn verbonden met een Git-opslagplaats, kunnen gebruikmaken van op Git gebaseerde ALM-functies.
Service-principals worden alleen ondersteund in de Fabric gegevensagent als onderdeel van ALM-scenario's. Als u wilt communiceren met een gegevensagent buiten ALM-werkstromen, wordt de service-principal niet ondersteund.
Implementatiepijplijnen vereisen dat de bron- en doelwerkruimten zich in dezelfde tenant bevinden.
Grote aantallen frequente commits kunnen van invloed zijn op de grootte en prestaties van de opslagplaats.

Feedback

Is deze pagina nuttig?

Last updated on 2026-08-27