Quellcodeverwaltung, CI/CD und ALM für Fabric-Daten-Agent (Vorschau)

In diesem Artikel wird beschrieben, wie Fabric-Daten-Agents mithilfe von Git-Integrations- und Bereitstellungspipelinen im Rahmen der Alm-Funktionen (Application Lifecycle Management) von Microsoft Fabric verwaltet werden. Sie erfahren, wie Sie einen Arbeitsbereich mit einem Git-Repository verbinden. Außerdem erfahren Sie, wie Sie Konfigurationen des Daten-Agents nachverfolgen und versionieren. Schließlich erfahren Sie, wie Sie Updates in Entwicklungs-, Test- und Produktionsumgebungen bewerben. Git-Integrations- und Bereitstellungspipelinen ermöglichen eine kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) von Daten-Agent-Änderungen, sodass Updates automatisch als Teil Ihres ALM-Workflows getestet und heraufgestuft werden können. Die Quellcodeverwaltung für Fabric-Datenagenten befindet sich derzeit in der Vorschauphase.

Sie können zwei ergänzende Ansätze verwenden, um ALM für Fabric-Daten-Agenten zu unterstützen.

• Git-Integration: Synchronisieren Sie einen gesamten Arbeitsbereich mit einem Git-Repository (entweder Azure DevOps oder GitHub als Git-Anbieter), um die Versionssteuerung, Zusammenarbeit über Branches und Verlaufsverfolgung für einzelne Elemente einschließlich Fabric-Datenagenten zu ermöglichen.
• Bereitstellungspipelines: Inhalte zwischen separaten Arbeitsbereichen hochstufen, die die Entwicklungs-, Test- und Produktionsphasen mithilfe integrierter Pipelines repräsentieren.

Diese Funktionen bieten gemeinsam End-to-End-ALM-Unterstützung für Fabric-Daten-Agents.

Voraussetzungen

• Eine kostenpflichtige F2- oder höhere Fabric-Kapazität oder eine Power BI Premium pro Kapazität (P1 oder höher) mit aktivierter Microsoft Fabric-Kapazität
• Fabric-Daten-Agent-Mandanteneinstellungen sind aktiviert.
• Die geoübergreifende Verarbeitung für KI ist aktiviert.
• Das geoübergreifende Speichern für KI ist aktiviert.
• Mindestens eine davon mit Daten: Ein Warehouse, ein Lakehouse, ein oder mehrere Power BI-Semantikmodelle, eine KQL-Datenbank oder eine Ontologie.
• Power BI-Semantikmodelle über den Mandantenwechsel von XMLA-Endpunkten sind für Power BI-Semantikmodelldatenquellen aktiviert.

Git-Integration

Die Microsoft Fabric Git-Integration synchronisiert einen Fabric-Arbeitsbereich mit einem Git-Repository, sodass Sie Ihre vorhandenen Entwicklungsprozesse, Tools und bewährten Methoden direkt auf der Fabric-Plattform verwenden können. Es unterstützt Azure DevOps und GitHub und ist auf Arbeitsbereichsebene verfügbar. Wenn Sie Änderungen von Fabric übernehmen, einschließlich Aktualisierungen der Daten-Agent-Konfiguration, werden diese Änderungen als Dateien im verbundenen Git-Repository gespeichert. Zu den wichtigsten Funktionen gehören:

• Vollständige Sicherung und Versionsverwaltung von Arbeitsbereichselementen
• Die Ordnerstruktur in Git spiegelt die Arbeitsbereichsstruktur wieder.
• Daten-Agent-Konfigurationen (Schemaauswahl, KI-Anweisungen, Datenquellenanweisungen, Beispielabfragen) werden in strukturierten Dateien in dedizierten Ordnern gespeichert.
• Möglichkeit, Unterschiede anzuzeigen, den Verlauf zu überprüfen und über die Verlaufshistorie zu vorherigen Zuständen zurückzukehren für Elemente des Arbeitsbereichs, einschließlich Datenagenten.
• Auf Zweigen basierende Zusammenarbeit (Feature Branches, Hauptzweig)

Weitere Informationen zum Git-Integrationsprozess finden Sie in den folgenden Ressourcen.

• Was ist die Microsoft Fabric Git-Integration?
• Grundlegende Konzepte in der Git-Integration
• Erste Schritte mit der Git-Integration

Einrichten einer Verbindung mit der Quellcodeverwaltung

Sie können Ihren Fabric-Arbeitsbereich über die Seite " Arbeitsbereichseinstellungen " mit einem Git-Repository verbinden. Mit dieser Verbindung können Sie Änderungen direkt aus Fabric übernehmen und synchronisieren.

1. Ausführliche Schritte zum Herstellen einer Verbindung mit einem Git-Repository in Azure DevOps oder GitHub finden Sie unter "Erste Schritte mit der Git-Integration ".

2. Nachdem Sie eine Verbindung mit dem Git-Repository hergestellt haben, werden Ihre Arbeitsbereichselemente, einschließlich Fabric-Daten-Agents, im Quellcodeverwaltungsbereich angezeigt. In der Statusleiste unten links sehen Sie den Namen der verbundenen Verzweigung, den Zeitpunkt der letzten Synchronisierung und die Git-Commit-ID.

3. Das verknüpfte Git-Repository zeigt eine Ordnerstruktur an, die Ihre Arbeitsbereichselemente einschließlich Fabric-Daten-Agents und deren Konfigurationsdateien darstellt. Jeder Daten-Agent wird in einem eigenen Ordner gespeichert, sodass Sie Änderungen überprüfen, den Versionsverlauf nachverfolgen und Git-Workflows wie das Erstellen von Pullanforderungen zum Zusammenführen von Updates in Ihre Hauptzweige verwenden können.

4. Wenn Sie Änderungen am Fabric-Daten-Agent in einem mit Git verbundenen Arbeitsbereich vornehmen, werden die Änderungen erkannt, und der Status des Daten-Agents im Bereich "Quellcodeverwaltung" ändert sich in "Nicht abgeschlossene Änderungen". Diese Änderungen können folgendes umfassen:

   • Ändern der Schemaauswahl.
   • Aktualisieren von KI-Anweisungen oder Datenquellenanweisungen.
   • Bearbeiten von Beispielabfragen.
   • Veröffentlichen des Daten-Agents oder Aktualisieren der Veröffentlichungsbeschreibung.

Jede Änderung – ob funktionell oder beschreibend – bewirkt, dass der Daten-Agent nicht mehr mit dem verknüpften Git-Repository synchronisiert wird. Die Arbeitsbereichselemente mit Änderungen werden unter der Registerkarte "Änderungen" im Bereich "Quellcodeverwaltung" angezeigt. Sie können diese Änderungen überprüfen, sie mit der zugesicherten Version vergleichen und sie zurück zum Git-Repository zur Synchronisierung übernehmen.

5. Wenn Aktualisierungen direkt im verknüpften Git-Repository (Azure DevOps oder GitHub) vorgenommen werden, können sie Aktionen wie das Ändern von KI-Anweisungen, das Ändern von Beispielabfragen oder das Bearbeiten von Veröffentlichungsbeschreibungen umfassen. Sie können dann commiten und diese Änderungen an das Repository übertragen. Sobald die Updates im Repository pushed und verfügbar sind, erkennt Ihr Fabric-Arbeitsbereich sie und zeigt eine verfügbare Benachrichtigung über Updates im Quellcodeverwaltungsbereich an. Die aktualisierten Elemente, z. B. der Daten-Agent, werden auf der Registerkarte "Updates" angezeigt, auf der Sie sie überprüfen und akzeptieren können. Wenn Sie diese Updates akzeptieren, werden die Repositoryänderungen auf Ihre Arbeitsbereichselemente angewendet, um sicherzustellen, dass der Arbeitsbereich die neueste zugesicherte Version in Git widerspiegelt.

Ordner- und Dateistruktur im Git-Repository

Im Folgenden überprüfen Sie die Struktur, wie die Konfiguration eines Datenagenten in einem Git-Repository gespeichert wird. Das Verständnis dieser Struktur ist wichtig für das Verwalten von Änderungen und die folgenden bewährten Methoden.

Stammstruktur

Im Stammverzeichnis werden die Daten-Agent-Inhalte unter dem Ordner "Dateien " gespeichert. Innerhalb von Dateien finden Sie einen Konfigurationsordner , der data_agent.json, publish_info.json, Entwurfsordner und veröffentlichten Ordner enthält.

Innerhalb des Konfigurationsordners enthält die publish_info.json die Veröffentlichungsbeschreibung für den Daten-Agent. Diese Datei kann aktualisiert werden, um die Beschreibung zu ändern, die angezeigt wird, wenn der Datenagent veröffentlicht wird.

Der Entwurfsordner enthält die Konfigurationsdateien, die der Entwurfsversion des Daten-Agents entsprechen, und der veröffentlichte Ordner enthält die Konfigurationsdateien für die veröffentlichte Version des Daten-Agents. Der Entwurfsordner enthält:

• Datenquellenordner , in denen es einen Ordner für jede Datenquelle gibt, die vom Daten-Agent verwendet wird.
  • Lakehouse- oder Warehouse-Datenquellen: Ordnernamen beginnen mit lakehouse-tables- oder warehouse-tables-, gefolgt vom Namen des Lakehouse oder Warehouse.
  • Semantische Modelldatenquellen: Ordnernamen beginnen mit semantic-model-, gefolgt vom Namen des semantischen Modells.
  • KQL-Datenbankdatenquellen: Ordnernamen beginnen mit kusto-, gefolgt vom Namen der KQL-Datenbank.
  • Ontology-Datenquellen: Ordnernamen beginnen mit ontology-, gefolgt vom Namen der Ontologie.

• stage_config.json enthält aiInstructions, die sich auf die Agentanweisungen bezieht.

Jeder Datenquellenordner enthält datasource.json und fewshots.json. Wenn es sich bei der Datenquelle jedoch um ein Semantikmodell handelt, werden Beispielabfragen nicht unterstützt, sodass der Ordner nur datasource.jsonenthält.

Die datasource.json definiert die Konfiguration für diese Datenquelle, einschließlich:

• dataSourceInstructions, das die Anweisungen für diese Datenquelle darstellt.

• displayName, der den Namen der Datenquelle anzeigt.

• elements, die sich auf die Schemazuordnung bezieht und eine vollständige Liste von Tabellen und Spalten aus der Datenquelle enthält.

  • Jede Tabelle verfügt über eine is_selected Eigenschaft. Wenn truedie Tabelle enthalten ist und wenn false, bedeutet dies, dass die Tabelle nicht ausgewählt ist und vom Daten-Agent nicht verwendet wird.
  • Spalteneinträge werden ebenfalls angezeigt is_selected, die Auswahl auf Spaltenebene wird derzeit jedoch nicht unterstützt. Wenn eine Tabelle ausgewählt ist, werden alle Spalten unabhängig vom Spaltenwert is_selected eingeschlossen. Wenn eine Tabelle nicht ausgewählt ist (is_selected: false auf Tabellenebene), werden keine Spalten berücksichtigt, obwohl is_selected auf true Spaltenebene eingestellt ist.

• Typkonventionen:

  • Wenn es sich bei dem Typ um eine Datenquelle handelt, handelt es sich einfach um den Datenquellentyp (z. B.: "type": "lakehouse_tables").
  • Wenn es sich bei dem Typ um eine Tabelle handelt, endet er mit .table (z. B.: "type": "lakehouse_tables.table").
  • Wenn der Typ eine Spalte ist, endet er mit .column (z. B.: "type": "lakehouse_tables.column").

Im fewshots.json werden Beispielabfragen für die Datenquelle gespeichert. Jeder Eintrag umfasst:

• id als eindeutiger Bezeichner für die Beispielabfrage.
• question, die sich auf die Frage der natürlichen Sprache bezieht.
• query zeigt den Abfragetext an, der je nach Datenquellentyp SQL oder KQL sein kann.

Der veröffentlichte Ordner spiegelt die Struktur des Entwurfsordners wider, stellt jedoch die veröffentlichte Version des Daten-Agents dar. Es empfiehlt sich, Dateien im veröffentlichten Ordner nicht direkt zu ändern. Änderungen sollten im Entwurfsordner vorgenommen werden. Sobald der Daten-Agent veröffentlicht wurde, sind diese Änderungen im veröffentlichten Ordner sichtbar. Dadurch wird sichergestellt, dass die veröffentlichte Version immer aus einem kontrollierten Entwurfszustand generiert wird.

Bereitstellungspipelines für Datenagenten

Bereitstellungspipelines bieten eine kontrollierte Möglichkeit, Datenagenten zwischen Arbeitsbereichen zu verschieben, die verschiedenen Lebenszyklusphasen zugeordnet sind. Beispiel:

1. Entwickeln Sie einen neuen Daten-Agent, oder aktualisieren Sie einen vorhandenen im Entwicklungsarbeitsbereich.
2. Änderungen in den Testarbeitsbereich zur Validierung verschieben.
3. Bewerben Sie die getesteten Änderungen an dem Produktionsarbeitsbereich, in dem sie endbenutzern zur Verfügung steht.

Vor der Bereitstellung müssen Sie jeder Phase in der Bereitstellungspipeline einen Arbeitsbereich zuweisen: Entwicklung, Test und Produktion. Wenn Sie der Test- oder Produktionsstufe keinen Arbeitsbereich zuweisen, werden die Arbeitsbereiche automatisch erstellt. Die automatisch erstellten Arbeitsbereiche werden nach dem Entwicklungsarbeitsbereich benannt, wobei [test] oder [prod] angefügt ist.

So stellen Sie Änderungen bereit:

• Wechseln Sie in der Pipeline zu der Phase, aus der Sie bereitstellen möchten (z. B. Entwicklung).
• Wählen Sie die Elemente im Arbeitsbereich aus, die Sie bereitstellen möchten.
• Wählen Sie "Bereitstellen" aus, um sie in die nächste Stufe zu befördern.

Sie können einen Bereitstellungsplan überprüfen, bevor Sie Änderungen anwenden, um sicherzustellen, dass nur beabsichtigte Updates höhergestuft werden. Weitere Informationen finden Sie unter "Erste Schritte mit Bereitstellungspipelines".

Veröffentlichen eines Fabric-Daten-Agents für die Bereitstellungspipelinen

Das Veröffentlichen eines Fabric-Daten-Agents macht ihn für die Verwendung in allen verschiedenen Verbrauchskanälen verfügbar, einschließlich Copilot für Power BI, Microsoft Copilot Studio und Azure AI Foundry Services. Um den Datenagenten über diese Kanäle hinweg zu bewerten und zu nutzen, muss der Datenagent veröffentlicht werden; Nicht veröffentlichte Daten-Agents sind nicht für den Verbrauch zugänglich, auch wenn sie sich im Produktionsarbeitsbereich befinden. Um die bewährten Methoden in Übereinstimmung mit der Bereitstellungspipeline zu befolgen, beachten Sie Folgendes:

• Die Veröffentlichung aus einem Entwicklungsarbeitsbereich sollte nur auf autorisierte Benutzer beschränkt sein, die an der Entwicklung von Daten-Agents arbeiten und ihre Leistung über verschiedene Verbrauchskanäle hinweg bewerten möchten. Der Zugriff auf diesen Arbeitsbereich muss eingeschränkt werden, damit unvollständige oder experimentelle Datenagenten keiner breiten Öffentlichkeit ausgesetzt werden.
• Endbenutzer sollten nur auf Daten-Agents zugreifen, die nur aus dem Produktionsarbeitsbereich veröffentlicht werden, um sicherzustellen, dass sie mit stabilen, genehmigten Versionen des Daten-Agents interagieren.

Dieser Ansatz unterstützt sowohl die funktionale Anforderung der Nutzungs- als auch leistungsbewertung und sorgt für eine ordnungsgemäße Zugriffssteuerung, indem Entwicklungs- und Produktionsumgebungen getrennt bleiben.

Bewährte Methoden

• Verwenden Sie einen dedizierten Branch für die Entwicklung von Data Agents, und nach der Code-Review in den Hauptbranch zusammenführen.
• Bewahren Sie verwandte Ressourcen (Datenquellen, Daten-Agents, Notizbücher und Pipelines) im selben Arbeitsbereich auf, um die Bereitstellung zu erleichtern.
• Testen Sie Daten-Agent-Änderungen im Testarbeitsbereich, bevor Sie die Produktion fördern.
• Verwenden Sie beschreibende Commit-Nachrichten, um den Verlauf leichter verständlich zu machen.
• Nehmen Sie nicht direkt Änderungen am veröffentlichten Ordner im Git-Repository vor.

Einschränkungen und Überlegungen

• Nur Arbeitsbereiche, die mit einem Git-Repository verbunden sind, können Git-basierte ALM-Features verwenden.
• Dienstprinzipale werden im Fabric-Daten-Agent nur in ALM-Szenarien unterstützt. Wenn Sie mit einem Daten-Agent außerhalb von ALM-Workflows interagieren müssen, wird ein Service Principal nicht unterstützt.
• Bereitstellungspipelinen erfordern, dass sich die Quell- und Zielarbeitsbereiche im selben Mandanten befinden.
• Große Anzahl häufiger Commits kann sich auf die Größe und Leistung von Repositorys auswirken.

Verwandte Inhalte

• Erste Schritte mit der Git-Integration
• Grundlegende Konzepte in der Git-Integration
• Was ist die Lebenszyklusverwaltung in Microsoft Fabric?