Git-Integration für die Entwicklung von Fabric-Lagerhäusern

Zutreffend für: ✅ Warehouse in Microsoft Fabric

Dieser Artikel erklärt die Vorteile der Entwicklung und Bereitstellung von Fabric Data Warehouse mit der integrierten Git-Integration von Fabric.

Important

Dieses Feature befindet sich in der Vorschauphase.

Durch die Verwendung von Git-Integration in Fabric können Teams moderne Versionskontrollpraktiken auf die Entwicklung von Lagerhäusern anwenden. Entwickler können Änderungen in Branches isolieren, die Entwicklung von Schemas über Commits verfolgen, durch Pull Requests zusammenarbeiten und Updates zwischen Git-Repositories und Fabric-Arbeitsbereichen synchronisieren.

Zu den typischen Szenarien gehören:

  • Sichere Entwicklung von Schemaänderungen in Zweigen und Arbeitsbereichen
  • Versionierung von Warehouse-Objekten in Git
  • Zusammenarbeit über mehrere Zweige und Arbeitsbereiche hinweg
  • Förderung validierter Veränderungen zwischen den Zweigstellen
  • Arbeitsbereichselemente (Lager und andere) mit der Git-Wahrheitsquelle in Einklang zu bringen

Um Konsistenz, Rückverfolgbarkeit und Zuverlässigkeit über die gesamten Lagerentwicklungslebenszyklen hinweg zu gewährleisten, müssen Sie diese Arbeitsabläufe verstehen.

Diagramm des Entwicklungszyklus der Fabric Warehouse Git-Integration.

Wenn du einen Fabric Data Warehouse Arbeitsbereich mit Git verbindest, committest du Warehouse-Definitionen als Datenbankprojekt. Dieses Projekt wird zur maßgeblichen Darstellung des Lagerhaus-Schemas in der Quellkontrolle und dient als Grundlage für laufende Entwicklungsaktivitäten. Im Quellcode-Explorer erscheint das Schema als einzelne .sql Dateien.

Screenshot des Schemas eines Lagers im Quellcode-Explorer.

Durch Fabric Git Integration und Fabric Data Warehouse können Sie:

Vergleich

Während dieses Synchronisationsprozesses verwendet Fabric eine DacFx-basierte inkrementelle Schema-Bereitstellung, um Änderungen anzuwenden. Dieser Ansatz wendet nur die relevanten Schemaunterschiede auf das Lager an, anstatt die gesamte Lagerdefinition zu aktualisieren.

Die inkrementelle Extraktion hilft, unnötige Änderungen in der Versionsverwaltung zu reduzieren, Schemaunterschiede über Branches hinweg übersichtlicher zu halten und effiziente Branching- und Merging-Workflows zu unterstützen. Da der Extraktionsprozess schema-bewusst ist, ermöglicht er auch einen zuverlässigen Vergleich und eine Validierung zwischen dem Workspace-Zustand und den Git-getrackten Definitionen.

Die Standardisierung, wie Warehouse-Schemata extrahiert und gespeichert werden, verbessert die Konsistenz zwischen Entwicklungsumgebungen. Schema-Definitionen bleiben über Zweige hinweg stabil, Unterschiede spiegeln absichtliche Entwicklungsänderungen genauer wider, und Quellcode-Kontrolle wird zu einer verlässlichen Basis für Deployment, Zusammenarbeit und Lebenszyklusmanagement.

Die XMLA.json Datei selbst wird während der Git-Integrations-Workflows ausgeschlossen. Fabric schließt diese Datei von Commits und Updates aus, sodass die standardmäßigen semantischen model Metadaten nicht unbeabsichtigt in Git gespeichert werden. Beim Synchronisieren eines Arbeitsbereichs aus Git wird XMLA.json ignoriert, wodurch Konflikte, unbeabsichtigte Überschreibungen und unnötige Änderungen beim Branch-Wechsel oder bei Aktualisierungen aus Git vermieden werden.

Einschränkungen bei der Quellcodeverwaltung

  • SQL-Sicherheitsfunktionen wie Berechtigungen erfordern einen skriptbasierten Ansatz für Export und Migration. Erwägen Sie die Verwendung eines Skripts nach der Bereitstellung in einem SQL-Datenbankprojekt. Sie können ein Post-Deployment-Skript im Projekt mit der SQL Database Projects-Erweiterung konfigurieren, die in Visual Studio Code verfügbar ist.

  • Cross-Item-Abhängigkeiten zwischen Lagern und SQL-Analytics-Endpunkten werden derzeit in Entwicklungsworkflows nicht unterstützt. Infolgedessen funktionieren Szenarien, die auf koordinierten Änderungen bei diesen Punkten angewiesen sind, möglicherweise nicht zuverlässig.

  • Pre-Deployment- oder Post-Deployment-Skripte sowie zusätzliche Veröffentlichungskonfigurationen, die direkt über Git zum Datenbankprojekt hinzugefügt werden, werden nicht als Teil der Entwicklungsworkflows erhalten. Möglicherweise musst du diese Konfigurationen außerhalb des Fabric-Arbeitsbereichs separat verwalten.

  • Selektive Commits auf Warehouse-Ebene werden derzeit nicht unterstützt. Änderungen werden auf Ebene der Lagerartikel durchgeführt und nicht auf feineren Granularobjektebenen.

  • Versionskontrollunterstützung für SQL-Analytics-Endpunkte ist derzeit nicht verfügbar. Diese Einschränkung kann das End-to-End-Lebenszyklusmanagement einschränken, wenn Lösungen sowohl Warehouses als auch SQL-Analytics-Endpunkte umfassen.

Einschränkungen bei der Git-Integration

  • Wenn zwei oder mehr Lagergegenstände aufeinander verweisen, bilden sie eine zyklische Abhängigkeit. Das System erkennt diese kreisförmige Referenz beim Erstellen von Branches oder bei Git-zu-Arbeitsbereich-Synchronisierungen, wodurch diese Vorgänge fehlschlagen. Vermeiden Sie zyklische Abhängigkeiten zwischen Gegenständen.
  • 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.
  • 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.
  • Wenn ein Objekt mithilfe der dreiteiligen Namensgebung (database.schema.object) auf ein anderes Objekt im selben Data Warehouse verweist, kann das Committen oder Aktualisieren aus Git fehlschlagen. Für weitere Informationen und einen Workaround siehe Referenzen auf die eigenen Objekte des Lagers unter Verwendung eines dreiteiligen Namens.
  • Wenn du eine Spalte änderst, für die IDENTITY definiert ist, können Commits oder Aktualisierungen von Git fehlschlagen, bis IDENTITY_INSERT für die Tabelle aktiviert ist.
  • Wenn das Repository eine Datei vom Typ .sqlproj enthält, die eine ältere Microsoft.Build.Sql SDK-Version festlegt, können Commits oder Aktualisierungen mit Git fehlschlagen, weil das ältere SDK neuere Warehouse-Syntax wie IDENTITY-Spalten und CLUSTER BY nicht erkennt. Für weitere Informationen und einen Workaround siehe Veraltete .sqlproj im Git-Repository.
  • Wenn ein Objekt auf zwei oder mehr Tabellen in einem anderen Warehouse verweist, ohne jede Spalte mit einem Alias zu qualifizieren, können Commits oder Aktualisierungen aus Git fehlschlagen. Für weitere Informationen und einen Workaround siehe Nicht qualifizierte Spalten in Objekten, die auf zwei oder mehr Tabellen in einem anderen Warehouse verweisen.
  • Wenn deine Skripte auf zwei oder mehr verschiedene Objekte im selben Schema eines anderen Warehouses verweisen und den Schemanamen mit uneinheitlicher Groß-/Kleinschreibung schreiben, kann das Committen oder Aktualisieren über Git fehlschlagen. Für weitere Informationen und einen Workaround siehe Inkonsistente Großschreibung von Schemanamen.
  • Mehrdeutige Spaltenfehler, deren Kandidatenliste einen :: Separator enthält, können beim Committen oder Aktualisieren von Git auftreten, selbst wenn keine echte Mehrdeutigkeit vorliegt. Weitere Informationen und Workarounds finden Sie unter Mehrdeutige Spaltenfehler mit doppelten Kandidatenobjekten.

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.

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

Nächster Schritt

Verwenden Sie Git Integration für die Entwicklung und Bereitstellung von Lagerhäusern

Verwandte Inhalte

  • Last updated on