Quellcodeverwaltung (Vorschau)

Gilt für:✅ Warehouse in Microsoft Fabric

In diesem Artikel wird erläutert, wie Git-Integrations- und Bereitstellungspipelinen für Lagerhäuser in Microsoft Fabric funktionieren. Erfahren Sie, wie Sie eine Verbindung mit Ihrem Repository einrichten, Ihre Warehouses verwalten und sie in verschiedenen Umgebungen bereitstellen. Die Quellcodeverwaltung für Fabric Warehouse ist derzeit ein Vorschaufeature.

Sie können sowohl Git-Integration als auch Bereitstellungspipelines für verschiedene Szenarien verwenden:

  • Verwenden Sie Git- und SQL-Datenbankprojekte, um inkrementelle Änderungen, Teamzusammenarbeit und Commit-Verlauf in einzelnen Datenbankobjekten zu verwalten.
  • Verwenden Sie Bereitstellungspipelines, um Codeänderungen an verschiedene Vorproduktions- und Produktionsumgebungen höher zu stufen.

Git-Integration

Die Git-Integration in Microsoft Fabric ermöglicht Entwicklern die direkte Integration ihrer Entwicklungsprozesse, Tools und bewährten Methoden in die Fabric Plattform. Sie ermöglicht Entwicklern, die sich in Fabric entwickeln, folgende Möglichkeiten:

  • Sichern und Versionieren ihrer Arbeit
  • Wiederherstellen vorheriger Phasen nach Bedarf
  • Mit anderen zusammenarbeiten oder allein arbeiten, indem Sie Git-Verzweigungen nutzen.
  • Anwenden der Funktionen vertrauter Quellcodeverwaltungstools zum Verwalten von Fabric Elementen

Weitere Informationen zum Git-Integrationsprozess finden Sie unter:

Einrichten einer Verbindung mit der Quellcodeverwaltung

Über die Seite Arbeitsbereichseinstellungen können Sie ganz einfach eine Verbindung mit Ihrem Repository einrichten, um Änderungen zu committen und zu synchronisieren.

  1. Informationen zum Einrichten der Verbindung finden Sie unter Erste Schritte mit der Git-Integration. Folgen Sie den Anweisungen, um eine Verbindung zu einem Git-Repository herzustellen, entweder zu Azure DevOps oder GitHub als Git-Anbieter.
  2. Nach dem Herstellen der Verbindung werden Ihre Elemente (einschließlich Warehouses) im Bereich Quellcodeverwaltung angezeigt. Screenshot aus dem Fabric-Portal des Lagers in den Quellverwaltungseinstellungen.
  3. Nachdem Sie die Warehouse-Instanzen erfolgreich mit dem Git-Repository verbunden haben, wird die Ordnerstruktur des Warehouse im Repository angezeigt. Sie können nun zukünftige Vorgänge ausführen, z. B. eine Pull Request erstellen.

Datenbankprojekte für ein Warehouse in Git

Die folgende Abbildung ist ein Beispiel für die Dateistruktur der einzelnen Warehouse-Elemente im Repository:

Screenshot aus dem Fabric Portal eines Beispiellagerschemas.

Wenn Sie das Warehouse-Element in das Git-Repository committen, wird das Warehouse als SQL-Datenbankprojekt in ein Quellcodeformat konvertiert. Ein SQL-Projekt ist eine lokale Darstellung von SQL-Objekten, die das Schema einer einzelnen Datenbank umfassen, z. B. Tabellen, gespeicherte Prozeduren oder Funktionen. Die Ordnerstruktur der Datenbankobjekte wird nach Schema/Objekttyp organisiert. Jedes Objekt im Warehouse wird mit einer SQL-Datei dargestellt, die die Definition der Datendefinitionssprache (Data Definition Language, DDL) enthält. Lagertabellendaten und SQL-Sicherheitsfeatures sind nicht im SQL-Datenbankprojekt enthalten.

Freigegebene Abfragen werden auch an das Repository committet und erben den Namen, unter dem sie gespeichert werden.

Bereitstellungspipelines

Sie können auch Bereitstellungspipelines verwenden, um Ihren Warehouse-Code in verschiedenen Umgebungen bereitzustellen, z. B. in der Entwicklungs-, Test- und Produktionsumgebung. Bereitstellungspipelines legen ein Datenbankprojekt nicht offen.

Führen Sie die folgenden Schritte aus, um Ihre Lagerbereitstellung mithilfe der Bereitstellungspipeline abzuschließen.

  1. Erstellen Sie eine neue Bereitstellungspipeline, oder öffnen Sie eine vorhandene Bereitstellungspipeline. Weitere Informationen finden Sie unter Erste Schritte mit Bereitstellungspipelines.
  2. Weisen Sie Arbeitsbereiche entsprechend Ihren Bereitstellungszielen verschiedenen Phasen zu.
  3. Elemente, einschließlich Lagerhäuser, zwischen verschiedenen Phasen auswählen, anzeigen und vergleichen, wie im folgenden Beispiel gezeigt. Screenshot aus dem Fabric Portal der Entwicklungs-, Test- und Produktionsphasen.
  4. Wählen Sie Einsetzen aus, um Ihre Warehouses in den Phasen Entwicklung, Test und Produktion einzusetzen.

Weitere Informationen zum Fabric Bereitstellungspipelineprozess finden Sie unter Introduction to deployment pipelines.

Einschränkungen bei der Quellcodeverwaltung

  • Sie müssen SQL-Sicherheitsfeatures mithilfe eines skriptbasierten Ansatzes exportieren oder migrieren. Erwägen Sie die Verwendung eines Skripts nach der Bereitstellung in einem SQL-Datenbankprojekt. Sie können dieses Skript konfigurieren, indem Sie das Projekt mit der Erweiterung SQL-Datenbankprojekte öffnen, die in Visual Studio Code verfügbar ist.

Einschränkungen bei der Git-Integration

  • Aktuell, wenn Sie ALTER TABLE verwenden, um eine Einschränkung oder Spalte im Datenbankprojekt hinzuzufügen, schlägt der Bereitstellungsprozess fehl und die Tabelle wird neu erstellt, was zu Datenverlust führt. Um die Tabellendefinition und -daten beizubehalten, sollten Sie die folgende Problemumgehung berücksichtigen:
    • Erstellen Sie eine neue Kopie der Tabelle im Data-Warehouse mithilfe von CREATE TABLE, INSERT, CREATE TABLE AS SELECT oder Klontabelle.
    • Ändern Sie die neue Tabellendefinition mit neuen Einschränkungen oder Spalten nach Bedarf mithilfe von ALTER TABLE.
    • Löschen Sie die alte Tabelle.
    • Benennen Sie die neue Tabelle mithilfe von sp_rename in den Namen der alten Tabelle um.
    • Ändern Sie die Definition der alten Tabelle im SQL-Datenbankprojekt auf exakt dieselbe Weise. Das SQL-Datenbankprojekt des Warehouse in der Quellcodeverwaltung und das Live-Warehouse sollten nun übereinstimmen.
  • Erstellen Sie momentan nicht ein Dataflow Gen2 mit einem Ausgabeziel für das Datenlager. Ein neues Element mit dem Namen DataflowsStagingWarehouse wird im Repository angezeigt und blockiert das Commit und Aktualisieren von Git.
  • Fabric Git-Integration unterstützt das SQL Analytics-Endpunktelement nicht.
  • Elementübergreifende Abhängigkeiten, Elementsequenzierung und Synchronisierungslücken zwischen dem SQL-Analyseendpunkt und dem Lager wirken sich auf die "Verzweigung zu einem neuen oder vorhandenen Arbeitsbereich" und "Wechseln zu einem anderen Zweig" während der Entwicklung und kontinuierlichen Integration aus.

Einschränkungen für Bereitstellungspipelines

  • Aktuell, wenn Sie ALTER TABLE verwenden, um eine Einschränkung oder Spalte im Datenbankprojekt hinzuzufügen, schlägt der Bereitstellungsprozess fehl und die Tabelle wird neu erstellt, was zu Datenverlust führt.
  • Erstellen Sie momentan nicht ein Dataflow Gen2 mit einem Ausgabeziel für das Datenlager. In der Bereitstellungspipeline wird ein neues Element DataflowsStagingWarehouse angezeigt und blockiert die Bereitstellung.
  • Fabric Bereitstellungspipelines unterstützen das SQL Analytics-Endpunktelement nicht.
  • Elementabhängigkeiten, Elementsequenzierung und Synchronisierungslücken zwischen dem SQL-Analyseendpunkt und dem Data Warehouse wirken sich auf die Workflows der Bereitstellungspipelines von Fabric aus.

Nicht unterstützte Szenarien

Die folgenden CI/CD-Workflows werden nicht offiziell unterstützt, wenn Lagerhäuser in verschiedenen Arbeitsbereichen unterschiedliche Sortierungen aufweisen. Obwohl diese Vorgänge ohne Fehler erfolgreich sein können, können sie zu Metadatenfehlern führen.

Verwenden Sie in all diesen Szenarien, wenn ein Sortierungsmissmatch auftritt, das Python-Skript scripts/dw-collation-error-update-tmsl/pbi_interactive.py im Werkzeugkasten des Fabric GitHub-Repositories, um die Sortierung des Datasets (TMSL) entsprechend der Lagersortierung zu aktualisieren.

Szenario Beschreibung Risiko
Bereitstellungspipelines Bewerben von Lagerinhalten über Pipelinephasen (z. B. Dev → Test → Prod), bei dem das Ziellager mit einer anderen Sortierung als die Quelle erstellt wurde, wird nicht unterstützt. Die Bereitstellung ist möglicherweise erfolgreich, die Datensatzzusammenführung wird jedoch nicht aktualisiert, um der Zusammenführung im Ziel-Datenlager zu entsprechen.
Verzweigen in einen neuen oder bestehenden Arbeitsbereich Die Verwendung der Git-Integration, um von einem bestehenden Arbeitsbereich in einen neuen oder bestehenden Arbeitsbereich zu verzweigen, in dem das Datenlager eine andere Sortierreihenfolge verwendet, wird nicht unterstützt. Lagerinhalte werden synchronisiert, die Sortierungsmetadaten werden jedoch nicht abgestimmt.
Wechseln von Verzweigungen in einem Arbeitsbereich Das Wechseln zu einer Zweigstelle, die einem Lager einer anderen Sortierung in einem mit Git verbundenen Arbeitsbereich zugeordnet war, wird nicht unterstützt. Synchronisierte Inhalte übernehmen möglicherweise Sortierannahmen, die nicht mit dem aktuellen Lager übereinstimmen.
Zusammenführen von Änderungen zwischen Arbeitsbereichen über Branches Das Zusammenführen von Git-Branches über Arbeitsbereiche hinweg, bei denen die Repositories unterschiedliche Sortierungen aufweisen, wird nicht unterstützt. Die Zusammenführung kann auf Git-Ebene erfolgreich sein, aber die resultierende Datensätze-Kollation spiegelt nicht die Kollation des Zieldatenlagers wider.