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

In diesem Artikel wird beschrieben, wie Sie Fabric Daten-Agenten mithilfe von Git-Integrations- und Bereitstellungspipelines im Rahmen der ALM-Funktionen (Anwendungslebenszyklusverwaltung) von Microsoft Fabric verwalten. 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 Vorschau.

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 Verzweigungen und Verlaufsverfolgung für einzelne Elemente einschließlich Fabric Daten-Agents 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-Datenagenten.

Voraussetzungen

• Eine bezahlte F2 oder höhere Fabric-Kapazität oder eine Power BI Premium pro Benutzer (P1 oder höher) Kapazität mit Microsoft Fabric aktiviert.
• Aktivieren Sie die geoübergreifende Verarbeitung und die geoübergreifende Speicherung für KI basierend auf den Anforderungen, die in den Fabric-Daten-Agent-Mandanteneinstellungen erläutert werden.
• Mindestens eine dieser Datenquellen mit Daten: Ein Warehouse, ein Lakehouse, ein Power BI-Semantikmodell, eine KQL-Datenbank, eine gespiegelte Datenbank oder eine Ontologie. Sie müssen über Lesezugriff auf die Datenquelle verfügen.

Git-Integration

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

Neueste Verbesserungen bei der Git-Integration

Fabric-Git-Integration unterstützt jetzt selektives Branching, sodass Sie den verbundenen Branch auf Ebene des Arbeitsbereichs wechseln können, um ihn an Feature-Branch-Workflows auszurichten. Der Bereich "Quellcodeverwaltung " bietet auch eine integrierte Diff-Erfahrung für Elementänderungen, sodass Sie genau überprüfen können, was vor dem Commit oder Abrufen von Updates geändert wurde. Verzweigte Arbeitsbereiche sind in der benutzeroberfläche Fabric deutlicher gekennzeichnet, wodurch leichter zu erkennen ist, mit welcher Verzweigung jeder Arbeitsbereich verbunden ist.

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

• Was ist die Microsoft Fabric Git-Integration?
• Grundkonzepte in der Git-Integration
• Mit der Git-Integration beginnen

Einrichten einer Verbindung mit der Quellcodeverwaltung

Sie können Ihren Fabric Arbeitsbereich über die Einstellungen für Workspace mit einem Git-Repository verbinden. Mit dieser Verbindung können Sie Änderungen direkt von Fabric übernehmen und synchronisieren.

1. Ausführliche Schritte zum Herstellen einer Verbindung mit einem Git-Repository in Azure DevOps oder GitHub finden Sie unter Get started with Git integration.

2. Nachdem Sie eine Verbindung mit dem Git-Repository hergestellt haben, werden Ihre Workspace-Elemente, einschließlich Fabric-Daten-Agents, im Quellsteuerungsbereich 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 übermittelte Ä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 bereitgestellt und verfügbar sind, erkennt Ihr Fabric-Arbeitsbereich sie und zeigt eine Benachrichtigung über verfügbare Updates im Bereich Quellcodeverwaltung 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. Wenn Sie Feature-Branches verwenden, nehmen Sie Änderungen an dem Branch vor, der mit dem Arbeitsbereich verknüpft ist, überprüfen Sie Diffs im Quellcodeverwaltungsbereich, und führen Sie sie über Pull-Anfragen für die kontrollierte Veröffentlichung zusammen. Die Datei- und Konfigurationsstruktur für Daten-Agenten bleibt über alle Branches hinweg gleich.

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

Automatisieren von CI/CD mit Azure DevOps Pipelines

Die Azure DevOps Pipelines-Erweiterung für Fabric stellt systemeigene Aufgaben bereit, die Fabric CLI Befehle in Azure DevOps Pipelineaufträgen ausführen. Teams können CI/CD für Daten-Agent-Updates mithilfe von Azure DevOps (mit der CLI) gemeinsam oder anstelle von Fabric-Bereitstellungspipelines orchestrieren. Um zu beginnen, installieren Sie die Erweiterung aus dem Visual Studio Marketplace, richten Sie eine Dienstverbindung in Ihrem Azure DevOps Projekt ein, und fügen Sie Ihrer Pipelinedefinition Fabric CLI-Aufgaben hinzu.

Massensynchronisierung über Batch-APIs (Vorschau)

Die Batch-APIs zum Importieren/Exportieren von Elementdefinitionen (Vorschau) bieten eine Option für die umfangreiche Synchronisierung von Elementdefinitionen, einschließlich Daten-Agent-Konfigurationen. Sie können Daten-Agent-Definitionen im Batch exportieren und importieren, um die Heraufstufung in allen Umgebungen zu optimieren. Weitere Informationen finden Sie in der Dokumentation zur Fabric REST-API.

Veröffentlichen Sie einen Fabric-Datenagent für die Bereitstellungspipelines

Die Veröffentlichung eines Fabric-Datenagents macht ihn für die Verwendung in allen verschiedenen Nutzungskanälen verfügbar, einschließlich Copilot für Power BI, Microsoft Copilot Studio und Foundry Tools. 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.
• Verwenden Sie umgebungsunabhängige Konfigurationsmuster (z. B. Verbindungsverweise über die Variablenbibliothek, sofern unterstützt), um umgebungsspezifische Werte in Datenquellenkonfigurationen des Datenagents zu vermeiden. Diese Vorgehensweise erleichtert reibungslose Branch-Merges und Bereitstellungen in Entwicklung, Test und Produktion.

Einschränkungen und Überlegungen

• Nur Arbeitsbereiche, die mit einem Git-Repository verbunden sind, können Git-basierte ALM-Features verwenden.
• Dienstprinzipale werden nur im Rahmen von ALM-Szenarien im Fabric-Datenagenten 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

• Mit der Git-Integration beginnen
• Grundkonzepte in der Git-Integration
• Was ist das Lebenszyklusmanagement in Microsoft Fabric?