Das Wichtigste in Kürze
- Die Fabric Variable Library ist die Umgebungskarte für Workspace- und Lakehouse-IDs über alle Stages.
- Automatisierung für Umbinden und Deployment liest die Library; hart kodierte GUIDs pro Stage sind in neuem Code verboten.
- Plattform- und Domänen-Workspaces sind ausdrückliche Zeilen mit verantwortlichen Personen.
- Für Änderungen an der Library ist eine Validierung gegen das Git-Schema Pflicht.
- Secrets leben nie in der Variable Library; die Topologie schon.
- Regressionen bei der Beförderung bekommen Playbooks, die zur Library gehören, und keinen Ersatz für sie.
Hart kodierte Workspace-IDs in Notebooks sind der Weg, auf dem Test versehentlich Prod umbindet. "Umgebungskarten" als Tabelle im Chat sind der Weg, auf dem zwei Teams zwei verschiedene Wahrheiten pflegen. Fabric liefert bereits ein besseres Zuhause: eine Variable Library in Git mit Value Sets pro Stage.
Leg die Werte für Test, Preprod und Prod im Element ab. Bring den Notebooks zum Umbinden bei, sie über unterstützte APIs zu lesen. Trenne Plattform- und Domänen-Workspaces ausdrücklich. Halte das Git-Schema ein, damit Wiederherstellungen funktionieren. Stell der Library eine Geschichte für die Beförderung zur Seite, wenn Parameter im Portal Regressionen haben.
Benanntes Modell: Umgebungskarte in der Variable Library
- Eine Library, Value Sets pro Stage: Workspaces, Lakehouses, Warehouses und die wichtigsten Verbindungsnamen mit Werten für Test, Preprod und Prod.
- Die Automatisierung liest die Karte: Notebooks zum Umbinden und Deployment-Helfer lösen IDs über die unterstützten Mechanismen der Variable Library auf, nicht über eingefügte GUIDs.
- Gekennzeichnete Verantwortung: Gemeinsame Zeilen der Plattform und Zeilen der Domänenprojekte bleiben ausdrücklich, damit der Betrieb nicht mehr raten muss.
- Vertrag: Wenn die Karte nicht in Git liegt und nicht von der Automatisierung gelesen wird, ist sie Folklore. Handänderungen, die das Schema brechen, sind eine eigene Klasse von Ausfällen.
Abbildung 1. Eine Variable Library in Git hält die Value Sets pro Stage. Die Automatisierung löst Ziele aus der Karte auf. Klebezettel und Tabellen im Chat skalieren nicht bis Prod.
Kontext und Rahmenbedingung
Ein häufiger Fehler: In Notebooks zum Umbinden sammeln sich GUID-Konstanten "nur für jetzt". Dieses Jetzt hält drei Stages und einen beängstigenden Beinahe-Unfall lang. Die Variable Library steht zur Verfügung. Teams tun trotzdem so, als würden Klebezettel skalieren.
Value Sets pro Stage gehören in die Variable Library. Automatisierung für Umbinden und Deployment sollte Workspace-IDs, Lakehouse-IDs und Verbindungsnamen aus dieser Karte auflösen. Plattform- und Domänen-Workspaces brauchen ausdrückliche Zeilen, damit die Leute nicht mehr raten. Von Hand bearbeitetes JSON, das das Schema des Elements verletzt, lässt Wiederherstellungen scheitern und kostet einen Tag. Wenn Parameter im Portal Regressionen haben, halte einen dokumentierten Workaround für die Beförderung neben der Library bereit, nicht an ihrer Stelle.
Abbildung 2 zeigt die Oberfläche in Learn zum Festlegen von Werten in einer Variable Library. Im Portal pflegst du die Sets; in Git muss die Wahrheit ehrlich bleiben.
Abbildung 2. Die Beförderung ist sicherer, wenn Workspace-Ziele aus einer Karte in der Variable Library kommen und nicht aus eingefügten GUIDs. Quelle: Microsoft Learn: Variable Library overview.
Design
1. Eine Library, Value Sets pro Stage
Pflege Variablen für die IDs, die die Automatisierung braucht: Workspaces, Lakehouses, Warehouses, die wichtigsten Verbindungsnamen. Fülle die Value Sets für Test, Preprod und Prod. Widersteh einem vierten, inoffiziellen Set "Dev auf meinem Laptop", das nie gepflegt wird. Lokale Overrides darf es geben; sie sollten die Karte nicht forken.
2. Über unterstützte Lesezugriffe umbinden, nicht über eingefügte GUIDs
Notebooks und Pipelines, die umbinden, sollten die Werte über die unterstützten Mechanismen der Variable Library oder über freigegebene Helfer der Plattform holen. GUIDs in Zellen einzufügen erschafft den Klebezettel neu, nur mit besserem Syntax-Highlighting. Das Code-Review sollte neue hart kodierte Workspace-IDs so ablehnen, wie es Secrets ablehnt. Abbildung 3 zeigt diese Weggabelung.
Abbildung 3. Eingefügte GUIDs erzeugen Archäologie. Unterstützte Lesezugriffe auf die Library verhindern, dass Test versehentlich Prod umbindet.
In meiner Demo enthält demo_varlib ein Standard-Value-Set plus Sets für Test, Preprod und Prod, wobei Test aktiv ist. Ein einziger Aufruf von notebookutils.variableLibrary in einem Notebook löst target_lakehouse zu demo_lakehouse_test und batch_size zu 1000 auf. Die Zelle nennt die Library, nie einen Wert einer Stage (Abbildung 4).
Abbildung 4. Eine Library, Value Sets pro Stage und ein Lesezugriff aus dem Notebook. Mit Test als aktivem Set löst die Zelle die Werte für Test auf, ohne dass ein Wert einer Stage im Code steht.
3. Plattform- und Domänen-Workspaces in der Karte trennen
Gemeinsame Kapazitäten der Plattform und Workspaces der Domänenprojekte tauchen beide auf, gekennzeichnet. Der Betrieb sollte sehen, welche Ziele gemeinsame Infrastruktur sind und welche einem Team gehören. Mehrdeutige Namen führen zu Umbindungen, die auf dem falschen Workspace "erfolgreich" sind. Abbildung 5 zieht außerdem die Grenze zu Secrets.
Abbildung 5. Kennzeichne Zeilen für Plattform und Domäne mit verantwortlichen Personen. Die Topologie lebt in der Variable Library. Secrets bleiben in Key Vault.
4. Das Git-Schema als Gesetz behandeln
Die Variable Library in Git hat eine Form. Handänderungen ohne Validierung gegen diese Form brechen Sync und Wiederherstellung. Nutze für strukturelle Änderungen lieber das Portal oder unterstützte Werkzeuge; wenn du doch von Hand bearbeiten musst, validiere. Eine kaputte Git-Historie ist hier eine Klasse von Ausfällen, keine Stilfrage.
5. Mit Playbooks für die Beförderung kombinieren
Wenn Parameter im Portal oder Bindungen von Direct Lake über Stages hinweg Regressionen haben, dokumentiere die vorübergehenden Maßnahmen neben der Library. Gib die Karte nicht auf, weil ein Beförderungsweg fehlerhaft ist. Workarounds ohne Karte werden zu dauerhaftem Stammeswissen.
6. Die Karte auffindbar machen
Verlinke die Library aus dem README der Plattform und aus den Runbooks zum Umbinden. Neue Engineers sollten die Karte in wenigen Minuten finden. Wenn nur zwei Personen den Namen des Elements kennen, hast du immer noch einen Klebezettel, nur mit Berechtigungen.
Was in die Library gehört und was in Key Vault
Die Variable Library ist für nicht geheime Topologie der Umgebungen da: IDs, Namen und Endpunkte, die keine Zugangsdaten sind. Secrets bleiben in Key Vault oder etwas Gleichwertigem. Secrets in die Library zu mischen lehrt das falsche Muster und verkompliziert Git. Wenn ein Wert sensibel ist, ist er kein Wert für die Variable Library. Wenn ein Wert eine Workspace-GUID ist, ist er genau ein Wert für die Variable Library. Zieh diese Grenze in der ADR, damit hilfsbereite Engineers die Topologie nicht mehr "absichern", indem sie sie in persönlichen Notizen vergraben.
Die Karte über Teams hinweg betreiben
Gib den Plattform-Engineers die Verantwortung für die gemeinsamen Zeilen. Gib den Domänenteams die Verantwortung für die Zeilen ihrer Workspaces, mit Review. Änderungen an den Value Sets für Prod sollten genauso streng geprüft werden wie Änderungen an Pipelines. Eine beiläufige Änderung einer Prod-ID ist eine Störung in Produktion mit besseren Manieren. Prüfe Diffs der Value Sets in PRs, wenn Git verbunden ist. Wenn im Portal geändert wird, exportiere oder synchronisiere zügig, damit Git nicht lügt.
Umbindungen in Test bei jeder Änderung der Karte per Smoke-Test prüfen
Wenn jemand eine Workspace-ID ändert, lass das Notebook zum Umbinden (oder eine Trockenprüfung) in Test gegen die neue Karte laufen, bevor du Preprod anfasst. Änderungen an der Karte ohne Smoke-Test sind der Weg, auf dem Tippfehler zu Ausfällen werden. Automatisiere in CI eine Prüfung "alle benötigten Keys auflösen", wenn du kannst; sonst mach sie zu einem Pflichtpunkt der Checkliste im PR.
Häufige Fehler
GUID-Archäologie in Notebooks. Umgebungen per Copy-paste. Test bindet Prod um.
Tabellen im Chat als Quelle der Wahrheit. Drift per Nachricht. Zwei Teams, zwei Karten.
Ein einziger Klumpen Variablen mit unklaren Sets pro Stage. Falsche Stage, selbstbewusstes Deployment.
Von Hand kaputtes Git-JSON. Die Wiederherstellung scheitert genau dann, wenn du sie brauchst.
Die Library nach einem Bug im Portal aufgeben. Die Folklore kehrt zurück. Workarounds werden zum System.
Nicht gekennzeichnete Plattform- und Domänenziele. Erfolgreiches Umbinden an die falsche Stelle.
So übernehmen oder anpassen
So übernehmen
- Die Fabric Variable Library als Umgebungskarte für Workspace- und Lakehouse-IDs über alle Stages.
- Automatisierung für Umbinden und Deployment, die die Library liest; hart kodierte GUIDs pro Stage sind in neuem Code verboten.
- Plattform- und Domänen-Workspaces als ausdrückliche Zeilen mit verantwortlichen Personen.
- Validierung gegen das Git-Schema für Änderungen an der Library.
- Secrets nie in der Variable Library; die Topologie gehört dorthin.
- Regressionen bei der Beförderung bekommen Playbooks, die zur Library gehören, und keinen Ersatz für sie.
Vor dem Einsatz anpassen
Zentrale Karten schaffen einen Punkt, an dem koordiniert werden muss. Verstreute GUIDs schaffen stille Schreibzugriffe über Umgebungen hinweg. Strenge Git-Hygiene bremst beiläufige Änderungen; beiläufige Änderungen brechen Wiederherstellungen. Variablen in der Automatisierung zu lesen kostet ein paar Zeilen Code und beseitigt eine ganze Klasse von Fehlern. Workarounds für die Beförderung kosten Dokumentation; undokumentierte Workarounds kosten Ausfälle.
Probier es selbst aus
Die Variable Library targets demo in meinem öffentlichen Repo tech-demos baut eine Library mit Value Sets für Test, Preprod und Prod und ein Notebook, das sie liest, sodass du das aktive Set wechseln und die Werte ohne Codeänderung umspringen sehen kannst.
Wichtigste Quellen: Fabric Variable Library und die Dokumentation zu Deployment Pipelines auf Microsoft Learn. Kombiniere sie mit deinem Runbook zum Umbinden, damit die Karte genutzt und nicht nur bewundert wird.
Leg die Karte in die Variable Library. Lies sie aus der Automatisierung. Halte Git ehrlich. Trenne Plattform und Domäne. Wenn sich die Beförderung danebenbenimmt, dokumentiere den Workaround neben der Karte. Klebezettel skalieren nicht bis Prod.
Verwandte Notizen
- Direct Lake on OneLake: Lohnt sich der Aufwand? (wenn eine vorübergehende literale Einstellung neben der Karte stehen muss)