Was ist die Microsoft Fabric-Git-Integration?
In diesem Artikel wird Entwickelnden erläutert, wie sie die Git-Versionskontrolle in das Microsoft Fabric Application Lifecycle Management-Tool (ALM) integrieren.
Hinweis
Einige der Elemente für die Git-Integration befinden sich in der Vorschauphase. Weitere Informationen finden Sie in der Liste der unterstützten Elemente.
Die Git-Integration in Microsoft Fabric ermöglicht es Entwicklern, ihre Entwicklungsprozesse, Tools und bewährten Methoden direkt in die Fabric-Plattform zu integrieren. Sie ermöglicht Entwicklern, die in Fabric entwickeln, Folgendes:
- Sichern und Versionieren ihrer Arbeit
- Wiederherstellen vorheriger Phasen nach Bedarf
- Mit anderen zusammenarbeiten oder alleine arbeiten mit Git-Branches
- Wenden Sie die Funktionen vertrauter Quellcodeverwaltungstools an, um Fabric-Elemente zu verwalten
Sehen Sie sich die Liste der unterstützten -Elementean.
Lesen Sie mehr über Git-Grundlagen und Konzepte der Versionskontrolle.
Erfahren Sie mehr über den Git-Integrationsprozess.
Erfahren Sie mehr über die beste Methode zum Verwalten Ihrer Git-Branches.
Datenschutzinformationen
Bevor Sie die Git-Integration aktivieren, sollten Sie sich über die folgenden möglichen Datenschutzerklärungen im Klaren sein:
- Datenschutzerklärung von Microsoft
- Azure DevOps Services Übersicht über den Datenschutz
- GitHub Datenschutz-Vereinbarung
Unterstützte Git-Anbieter
Die folgenden Git-Anbieter werden unterstützt:
- Git in Azure Repos mit demselben Mandanten wie dem Fabric-Mandanten
- GitHub- (nur Cloudversionen)
- GitHub Enterprise- (nur Cloudversionen)
Unterstützte Elemente
Die folgenden Elemente werden derzeit unterstützt:
- Datenpipelines(Vorschau)
- Dataflows Gen2(Vorschau)
- Eventhouse- und KQL-Datenbank(Vorschau)
- Eventstream(Vorschau)
- Lakehouse(Vorschau)
- Gespiegelte Datenbank(Vorschau)
- Notebooks
- Paginierte Berichte(Vorschau)
- Reflex (Vorschau)
- Berichte (mit Ausnahme von Berichten, die mit semantischen Modellen verbunden sind, die in Azure Analysis Servicesoder SQL Server Analysis Servicesgehostet werden, oder Berichte, die von Power BI Desktop exportiert wurden und von semantischen Modellen abhängen, die in MyWorkspacegehostet werden) (Vorschau)
- Semantische Modelle (außer Pushdatasets, Liveverbindungen zum Analysis Services-Modell v1) (Vorschau)
- Spark-Auftragsdefinitionen(Vorschau)
- Spark-Umgebung(Vorschau)
- SQL-Datenbank(Vorschau)
- Warehouses(Vorschau)
Wenn der Arbeitsbereich oder das Git-Verzeichnis nicht unterstützte Elemente enthält, kann er trotzdem weiterhin verbunden sein. Die nicht unterstützten Elemente werden jedoch ignoriert. Sie werden nicht gespeichert oder synchronisiert, aber auch nicht gelöscht. Sie werden im Quellcodeverwaltungsbereich angezeigt, aber Sie können sie weder committen noch aktualisieren.
Überlegungen und Einschränkungen
Allgemeine Einschränkungen bei der Git-Integration
- Die Authentifizierungsmethode in Fabric muss mindestens so stark sein wie die Authentifizierungsmethode für Git. Wenn Git beispielsweise eine Multi-Faktor-Authentifizierung erfordert, muss Fabric auch eine Multi-Faktor-Authentifizierung erfordern.
- Power BI-Datasets, die mit Analysis Services verbunden sind, werden derzeit nicht unterstützt.
- Arbeitsbereiche mit installierten Vorlagen-Apps können nicht mit Git verbunden werden.
- Untermodule werden nicht unterstützt.
- Sovereign Clouds werden nicht unterstützt.
- Das Azure DevOps-Konto muss für den Benutzer registriert werden, der auch den Fabric-Arbeitsbereich verwendet.
- Azure DevOps wird nicht unterstützt, wenn Überprüfung bedingter IP-Zugriffsrichtlinien aktivieren aktiviert ist.
- Der Mandantenadministrator muss geoübergreifende Exporte aktivieren, wenn sich der Arbeitsbereich und das Git Repository in zwei verschiedenen geografischen Regionen befinden.
- Wenn Ihre Organisation den bedingten Zugriff konfiguriert hat, stellen Sie sicher, dass im Power BI-Dienst wie erwartet dieselben Bedingungen für die Authentifizierung festgelegt sind.
- Das Größenlimit für ein Commit beträgt 125 MB.
GitHub Enterprise-Einschränkungen
Einige GitHub Enterprise-Einstellungen werden nicht unterstützt. Zum Beispiel:
- Liste zugelassener IP-Adressen
- Privates Netzwerk
- Benutzerdefinierte Domänen
Einschränkungen des Arbeitsplatzes
- Nur der Arbeitsbereichs-Admin ist in der Lage, Verbindungen mit dem Git-Repository zu verwalten, also z. B. Verbindungen herzustellen bzw. zu trennen oder einen Branch hinzuzufügen.
Sobald die Verbindung hergestellt wurde, kann jeder mit der geeigneten Berechtigung im Arbeitsbereich arbeiten.
Einschränkungen bei Branches und Ordnern
- Ein Branchname darf maximal 244 Zeichen lang sein.
- Die maximale Länge des vollständigen Pfads für Dateinamen beträgt 250 Zeichen. Längere Namen verursachen Fehler.
- Die maximale Dateigröße beträgt 25 MB.
- Die Ordnerstruktur wird bis zu 10 Ebenen tief beibehalten.
- Sie können einen Bericht/ein Dataset nicht als PBIX-Datei aus dem Dienst herunterladen, nachdem Sie diese mit der Git-Integration bereitgestellt haben.
- Wenn der Anzeigename des Elements eines dieser Merkmale aufweist, wird der Git-Ordner in die logische ID (Globally Unique Identifier, GUID) und den entsprechenden Typ umbenannt:
- mehr als 256 Zeichen enthält,
- Endet mit einem Punkt (.) oder einem Leerzeichen
- Enthält unzulässige Zeichen (siehe Einschränkungen für Verzeichnisnamen)
- Wenn Sie einen Arbeitsbereich mit Ordnern mit Git verbinden, müssen Sie Änderungen am Git-Repository übernehmen, wenn diese Ordnerstruktur unterschiedlich ist.
Einschränkungen für Verzeichnisnamen
Der Name des Verzeichnisses, das eine Verbindung mit dem Git-Repository herstellt, hat die folgenden Benennungseinschränkungen:
- Der Verzeichnisname kann nicht mit einem Leerzeichen oder einer Registerkarte beginnen oder enden.
- Der Verzeichnisname darf keines der folgenden Zeichen enthalten: "/:<>\*?|
Der Elementordner (der Ordner, der die Elementdateien enthält) darf keines der folgenden Zeichen enthalten: ":<>\*?|. Wenn Sie den Ordner in etwas umbenennen, das eines dieser Zeichen enthält, kann Git keine Verbindung mit dem Arbeitsbereich herstellen oder synchronisieren, und ein Fehler tritt auf.
Verzweigungseinschränkungen
- Für das Verzweigen sind die Berechtigungen erforderlich, die in der Berechtigungstabelle aufgeführt sind.
- Für diese Aktion muss eine verfügbare Kapazität vorhanden sein.
- Alle Arbeitsbereichs- und Brachnamensbeschränkungen gelten auch bei Verzweigungen in einen neuen Arbeitsbereich.
- Nur unterstützte Git-Elemente sind im neuen Arbeitsbereich verfügbar.
- In der Liste der zugehörigen Branches werden nur Branches und Arbeitsbereiche angezeigt, die Sie sehen dürfen.
- Die Git-Integration muss aktiviert sein.
- Beim Verzweigen wird eine neue Verzweigung erstellt, und die Einstellungen aus der ursprünglichen Verzweigung werden nicht kopiert. Passen Sie alle Einstellungen oder Definitionen an, um sicherzustellen, dass das neue die Richtlinien Ihrer Organisation erfüllt.
- Beim Wechseln zu einem vorhandenen Arbeitsbereich:
- Der Zielarbeitsbereich muss eine Git-Verbindung unterstützen.
- Der Benutzer muss ein Administrator des Zielarbeitsbereichs sein.
- Der Zielarbeitsbereich muss über Kapazität verfügen.
- Der Arbeitsbereich kann keine Vorlagen-Apps enthalten.
- Beachten Sie, dass beim Verzweigen zu einem Arbeitsbereich alle Elemente, die nicht auf Git gespeichert sind, verloren gehen können. Es wird empfohlen, alle Elemente, die Sie beibehalten möchten, vor dem Verzweigen zu committen.
Einschränkungen bei Synchronisierungen und Commits
- Die Synchronisierung kann jeweils nur in eine Richtung ausgeführt werden. Commits und Updates können nicht gleichzeitig ausgeführt werden.
- Vertraulichkeitsbezeichnungen werden nicht unterstützt, und das Exportieren von Elementen mit Vertraulichkeitsbezeichnungen ist möglicherweise deaktiviert. Um Elemente mit Vertraulichkeitsbezeichnungen ohne die Vertraulichkeitsbezeichnung zu committen, bitten Sie Ihr Administratorteam um Unterstützung.
- Funktioniert mit einer begrenzten Anzahl von Elementen. Nicht unterstützte Artikel im Ordner werden ignoriert.
- Das Duplizieren von Namen ist nicht zulässig. Selbst wenn Power BI die Namensduplikation zulässt, schlägt die Aktion zum Aktualisieren, Committen oder Rückgängigmachen fehl.
- B2B wird nicht unterstützt.
- Konflikte werden teilweise in Git gelöst.
- Während des Commit-Vorgangs an Git löscht der Fabric-Dienst alle Dateien im Artikel-Ordner, die nicht Teil der Artikel-Definition sind. Nicht verknüpfte Dateien, die sich nicht in einem Artikel-Ordner befinden, werden nicht gelöscht.
- Nach dem Committen von Änderungen werden Sie möglicherweise einige unerwartete Änderungen an dem Element feststellen, die Sie nicht vorgenommen haben. Diese Änderungen sind semantisch unbedeutend und können aus verschiedenen Gründen auftreten. Beispiel:
- Manuelles Ändern der Elementdefinitionsdatei. Diese Änderungen sind gültig, können sich aber von denen unterscheiden, die über die Editors vorgenommen werden. Wenn Sie beispielsweise eine Semantikmodellspalte in Git umbenennen und diese Änderung in den Arbeitsbereich importieren, wird die BIM-Datei beim nächsten Commit von Änderungen an das Semantikmodell als geändert registriert, und die geänderte Spalte wird an das Ende des
columns
-Arrays gepusht. Dies liegt daran, dass die AS-Engine, die die BIM-Dateien generiert, umbenannte Spalten an das Ende des Arrays pusht. Diese Änderung wirkt sich nicht auf die Funktionsweise des Elements aus. - Committen einer Datei, die CRLF-Zeilenumbrüche verwendet: Der Dienst verwendet Zeilenumbrüche (LF, Line Feed). Wenn sich im Git-Repository Dateien mit CRLF-Zeilenumbrüchen befanden, werden diese Dateien beim Committen vom Dienst in LF geändert. Wenn Sie beispielsweise einen Bericht auf dem Desktop öffnen, speichern Sie die Projektdatei (.pbip) und laden Sie sie mit CRLFin Git hoch.
- Manuelles Ändern der Elementdefinitionsdatei. Diese Änderungen sind gültig, können sich aber von denen unterscheiden, die über die Editors vorgenommen werden. Wenn Sie beispielsweise eine Semantikmodellspalte in Git umbenennen und diese Änderung in den Arbeitsbereich importieren, wird die BIM-Datei beim nächsten Commit von Änderungen an das Semantikmodell als geändert registriert, und die geänderte Spalte wird an das Ende des
- Beim Aktualisieren eines Semantikmodells mithilfe der API für erweiterte Aktualisierungen wird nach jeder Aktualisierung ein Git-Diff erstellt.