Broncodebeheer, CI/CD en ALM voor Fabric-gegevensagent (preview)

In dit artikel wordt beschreven hoe u Fabric-gegevensagents beheert met behulp van Git-integratie- en implementatiepijplijnen als onderdeel van de MOGELIJKHEDEN van Application Lifecycle Management (ALM) van Microsoft Fabric. 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-gegevensagents is momenteel beschikbaar als preview-versie.

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

Git-integratie: Synchroniseer een volledige werkruimte met een Git-opslagplaats (Azure DevOps of GitHub als een Git-provider) om versiebeheer, samenwerking via vertakkingen en geschiedenistracking mogelijk te maken voor afzonderlijke items, waaronder Fabric-gegevensagents.
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.

Belangrijk

Deze functie is beschikbaar als preview-versie.

Vereiste voorwaarden

Een betaalde F2- of hogere infrastructuurcapaciteit of een Power BI Premium-capaciteit per capaciteit (P1 of hoger) waarvoor Microsoft Fabric is ingeschakeld
De tenantinstellingen van de Fabric-data-agent zijn ingeschakeld.
Cross-geo verwerking voor AI is ingeschakeld.
Cross-geo-opslag voor AI is ingeschakeld.
Ten minste één van deze, met gegevens: Een magazijn, een lakehouse, een of meer semantische Power BI-modellen, een KQL-database of een ontologie.
Power BI-semantische modellen via XMLA-eindpunt-tenantwissel is ingeschakeld voor Power BI-semantische modelgegevensbronnen.

Git-integratie

Microsoft Fabric Git-integratie synchroniseert een Fabric-werkruimte met een Git-opslagplaats, zodat u uw bestaande ontwikkelprocessen, hulpprogramma's en aanbevolen procedures rechtstreeks in het Fabric-platform kunt gebruiken. Het biedt ondersteuning voor Azure DevOps en GitHub en is beschikbaar op werkruimteniveau. Wanneer u wijzigingen vanuit Fabric doorvoert, 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)

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

Wat is Microsoft Fabric Git-integratie?
Basisconcepten in Git-integratie
Aan de slag met Git-integratie

Een verbinding met broncodebeheer instellen

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

Zie Aan de slag 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, inclusief 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-gegevensagents en hun 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 werkruimte die is verbonden met Git, 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 uitgevoerd 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 wordt er een melding weergegeven met updates beschikbaar in het deelvenster Bronbeheer. 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.

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

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, die verwijst naar de vraag in natuurlijke taal.
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.

Opmerking

Service-principals worden alleen ondersteund in de Fabric-gegevensagent 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 functies van de Fabric-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 Azure AI Foundry Services. 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.

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 2025-10-04