Microsoft Fabric Workspace-Einrichtung für Teams mit mehreren Entwicklern

Über diese Serie

Microsoft Fabric macht den Einstieg mit einem einzelnen Arbeitsbereich und einem einzelnen Entwickler leicht. Sobald Sie ein Team hinzufügen, stellen sich unübersichtlichere Fragen: wer arbeitet wo, wie werden Zweige und Arbeitsbereiche synchronisiert und wie kann man allen nutzbare Daten zur Verfügung stellen, ohne das Lakehouse wiederholt zu klonen.

In Teil 1 sind wir in einem einzigen Arbeitsbereich geblieben und haben uns auf die interne Struktur und die Namensgebung konzentriert. In diesem Beitrag zoomen wir eine Ebene weiter: wie Sie mehrere Arbeitsbereiche und Git-Zweige einrichten, damit mehrere Entwickler parallel arbeiten können , ohne ständig ihr eigenes Seehaus neu zu bauen.

Das Problem: Multi-Entwickler-Chaos auf Fabric

Die Happy Path-Demo zeigt normalerweise einen einzelnen Entwickler in einem einzigen Arbeitsbereich. Echte Projekte sehen nicht so aus. Im wirklichen Leben:

Dieser letzte Punkt ist der Punkt, an dem es interessant wird:

Ein Arbeitsbereich kann immer nur mit einem Git-Zweig verknüpft werden. Sie können ändern, auf welchen Zweig er verweist, aber es handelt sich immer um eine Eins-zu-Eins-Beziehung.

Das wirft sofort eine Frage auf:

Darüber hinaus stoßen Sie schnell auf ein zweites Problem: Daten.

Selbst wenn Sie das Problem mit den Arbeitsbereichen und Zweigen gelöst haben, kann es vorkommen, dass Sie Arbeitsbereiche haben, die zwar technisch "fertig" sind, aber keine nützlichen Daten enthalten.

In diesem Beitrag geht es um die Einrichtung, die sowohl die Zusammenarbeit als auch den Datenzugriff möglich macht.

Kurzes Resümee: Was Git synchronisiert (und nicht synchronisiert)

Wir brauchen hier nur ein leichtes mentales Modell:

Item type	Git synced?	Notes
Workspace	No	Just a container. Binding to a branch is a setting, not in Git.
Lakehouse / Warehouse	Partially	Item + schema/metadata synced. Data is not in Git. Each workspace can have its own instance of a lakehouse item, but only some of them will actually contain data.
Notebook / Pipeline / Dataflow	Yes	Definitions stored as artifacts in Git.

Die wichtigste Folge:

Ein brandneuer Feature-Arbeitsbereich, der mit einer Verzweigung verknüpft ist, zieht Notebooks, Pipelines, semantische Modelle und die leere Hülle Ihres Lakehouses herunter, verfügt aber nicht auf magische Weise über eine vollständige Kopie Ihrer Lakehouse-Daten.

Wenn wir in diesem Zusammenhang von "Wiederaufbau" oder "Rehydrierung" eines Lakehouse sprechen, meinen wir damit die gesamte Abfolge von Schritten, die erforderlich sind, um diese leere Hülle wieder in etwas für die Entwicklung Brauchbares zu verwandeln: das erneute Ausführen von Ingestion-Pipelines, die Neuerstellung von Tabellen, das Kopieren oder Wiederherstellen von Daten und manchmal auch die Korrektur von Berechtigungen und Konfigurationen.

Wenn jeder Entwickler "sein" Lakehouse als primäre Datenquelle behandeln würde, müsste immer noch jemand dieses Lakehouse rehydrieren: die Ingestion erneut ausführen, Daten kopieren oder einen manuellen Import durchführen. Das wird sehr schnell langweilig.

Schauen wir uns zunächst die Arbeitsplatzoptionen an, die Teams normalerweise in Betracht ziehen.

Option 1: Alle im gleichen Entwicklungsarbeitsbereich und in der gleichen Niederlassung

Die offensichtlichste Variante:

Auf dem Papier:

In der Praxis stoßen Sie schnell auf Probleme:

Wann kann dies noch akzeptabel sein (aber dennoch nicht empfohlen)?

Für fast alle anderen wird dies schneller zum Engpass, als Sie zugeben möchten.

Option 2: Zentraler Entwicklungs-/Test-/Prozessbereich + persönliche Arbeitsbereiche für Funktionen

Die von Microsoft empfohlene Richtung sieht folgendermaßen aus.

Zusammen mit einem eher klassischen Git-Verzweigungsmodell:

Das Konzept dieses Systems bietet eine Menge Vorteile:

Aber wenn Sie es naiv umsetzen, stoßen Sie auf das bereits erwähnte Problem der Rehydrierung.

Brandneuer persönlicher Arbeitsbereich + Feature Branch = Code-Definitionen und eine leere Lakehouse-Hülle, aber standardmäßig keine nützlichen Daten.

Das Prinzip: Nur zentrale Arbeitsbereiche werden mit Daten bestückt

Hier ist die Schlüsselidee, die den Schmerz des "Rehydrierens des Seehauses" beseitigt und gleichzeitig jedem einen Seehausartikel in seinem Arbeitsbereich bietet:

Lakehouses werden über Git mit jedem Arbeitsbereich synchronisiert, aber nur der zentrale Arbeitsbereich wird mit echten Daten befüllt. Die Feature-Arbeitsbereiche haben die gleichen Lakehouse-Definitionen, aber diese bleiben meist leer und sind nicht die primäre Datenquelle.

Wonach das aussieht:

Dies ist der Teil, der sich in der Benutzeroberfläche von Fabric kontraintuitiv anfühlt:

Warum es sich lohnt:

Wenn ein Entwickler einen neuen Funktionsarbeitsbereich erstellt, ihn mit einer Verzweigung verknüpft und synchronisiert, kann er die Notizbücher sofort mit echten Entwicklungsdaten vergleichen. Kein zusätzliches Einlesen, kein manuelles Kopieren, kein benutzerdefinierter Rehydrierungsschritt.

Sie haben zwei Anliegen getrennt:

Ein ganz normaler Tag: Entwicklerfluss

Aus der Sicht eines Entwicklers sieht eine typische Funktion wie folgt aus:

Das haben Sie zu keinem Zeitpunkt getan:

Arbeitsbereichsübergreifender Zugriff: Große Leistung, scharfe Kanten

Mit Stoffen können Sie Ihre Arbeitsbereiche ganz einfach kombinieren:

Das ist es, was solche Muster ermöglicht:

So weit, so gut. Die scharfe Kante erscheint nur, wenn Git und Löschungen ins Spiel kommen.

Im Moment kann die Git-Synchronisierung fehlschlagen, wenn ein Commit ein Element in einem Arbeitsbereich löscht, während dasselbe Element noch von einem anderen Arbeitsbereich referenziert wird. Wenn Dev versucht, mit diesem Commit zu synchronisieren, erkennt Fabric, dass das Löschen diese arbeitsbereichsübergreifenden Referenzen zerstören würde und verweigert die Synchronisierung.

Dies zeigt sich häufig bei der Einrichtung von Funktionsarbeitsbereichen.

Beispiel: Löschen einer Pipeline in einem Feature-Arbeitsbereich

Stellen Sie sich vor, Sie haben:

Nun entscheiden Sie, dass pl_ingest_customers für Ihr Feature nicht mehr benötigt wird:

Aus der Sicht von Git besagt der Commit: "pl_ingest_customers ist weg."
Aber in dem anderen Arbeitsbereich gibt es immer noch eine Pipeline oder einen Datenfluss, der auf pl_ingest_customers verweist.

Wenn Dev versucht, zu synchronisieren:

Aus Ihrer Perspektive fühlt sich das so an:

Ich habe gerade eine Pipeline in meinem Feature-Arbeitsbereich bereinigt. Warum lässt sich Dev nicht mehr synchronisieren?

Aus der Sicht von Fabric verhindert es, dass Sie einen anderen Arbeitsbereich beschädigen, der auf dasselbe Repository zurückgreift.

Was Sie damit in der Praxis tun können

Dieses Sicherheitsnetz ist nützlich, aber es bedeutet auch, dass Sie sich genau überlegen müssen, wo Sie Abhängigkeiten zwischen Elementen schaffen.

Faustformel:

Wie dies in das Muster des zentralisierten Seehauses passt

Für das zentralisierte Seehaus in diesem Beitrag bedeutet das Folgendes:

Indem Sie fast alle Abhängigkeiten von Element zu Element lokal in einem Arbeitsbereich halten und nur das Lakehouse selbst zentralisieren, verringern Sie die Wahrscheinlichkeit, dass eine kleine Bereinigung in einem Funktionszweig die Git-Synchronisierung für alle anderen blockiert, erheblich.

Do's und Don'ts für die Skalierung des Arbeitsbereichs

Um dies zu konkretisieren, finden Sie hier eine kurze Liste, die Sie zu Teamkonventionen machen können.

Do's

Tadeln

Zusammenfassung

Mit einer internen Struktur (Teil 1) und der Einrichtung eines Arbeitsbereichs für mehrere Entwickler (dieser Beitrag) haben Sie ein Skelett, das sowohl in die Tiefe (mehr Artefakte) als auch in die Breite (mehr Entwickler) skaliert.

Wenn Sie mit Ihrer eigenen Workspace-Topologie experimentieren und dabei auf scharfe Kanten stoßen, insbesondere im Zusammenhang mit Workspace-übergreifenden Abhängigkeiten und der Git-Synchronisierung, würde ich mich freuen, Ihre Erfahrungen zu hören - sie sind genau die Art von Feedback aus der Praxis, auf der diese Serie aufbaut.