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.

Inkrementelle Extraktion hilft, unnötige Wechsel in der Quellcodekontrolle zu reduzieren, sauberere Schemaunterschiede zwischen den Zweigstellen zu erhalten und effiziente Verzweigungs- und Zusammenführungsworkflows 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 dies XMLA.json ignoriert, was hilft, Konflikte, unbeabsichtigte Überschreibungen und Störungen während des Verzweigungswechsels oder Updates von Git zu vermeiden.

Einschränkungen bei der Quellcodeverwaltung

SQL-Sicherheitsfunktionen wie Berechtigungen erfordern einen separaten Export- und Migrationsansatz.

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

  • 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 zirkuläre Referenz während Verzweigungen oder Git-zu-Arbeitsbereich-Synchronisationsoperationen, was dazu führt, dass diese Operationen 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 ein anderes Objekt im selben Warehouse mithilfe der dreiteiligen Benennung (database.schema.object) referenziert, kann das Committen oder Aktualisieren von Git ausfallen. 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, die definiert ist IDENTITY , kann Commit oder Update aus Git fehlschlagen, bis IDENTITY_INSERT für die Tabelle aktiviert ist.
  • Wenn das Repository eine .sqlproj Datei enthält, die eine ältere Microsoft.Build.Sql SDK-Version anpinnt, kann das Committen oder Aktualisieren von Git ausfallen, weil das ältere SDK neuere Warehouse-Syntax wie IDENTITY Spalten und CLUSTER BYnicht erkennt. Für weitere Informationen und einen Workaround siehe Veraltete .sqlproj im Git-Repository.
  • Wenn ein Objekt zwei oder mehr Tabellen in einem anderen Warehouse referenziert, ohne jede Spalte zu aliasqualifizieren, kann das Commit oder Aktualisieren von Git aus fehlschlagen. Für weitere Informationen und einen Workaround siehe Unqualified columns in objects that reference to to oder mehr tables in einem anderen Warehouse.
  • Wenn deine Skripte zwei oder mehr verschiedene Objekte im selben Schema eines anderen Warehouses referenzieren und den Schemanamen mit inkonsistenter Großschreibung schreiben, kann das Committen oder Aktualisieren von Git ausfallen. 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