Fabric Deployment Pipelines: Der schnelle Einstieg und seine Grenzen

Wer in Microsoft Fabric zum ersten Mal über den Weg von der Entwicklung in die Produktion nachdenkt, landet fast zwangsläufig bei den Deployment Pipelines. Sie sind direkt im Fabric-Portal eingebaut und führen den Ansatz fort, den viele schon aus den Power BI Deployment Pipelines kennen.

Dieser Beitrag ist der zweite Teil unserer Serie zu CI/CD in Microsoft Fabric. Der erste Teil hat gezeigt, warum Deployment eine Architekturentscheidung ist, und drei Ebenen eingeführt, die in jeder Umgebung neu verdrahtet werden müssen: die Prozess-Ebene mit Lakehouse oder Warehouse, Notebooks, Pipelines und Shortcuts, die Modell-Ebene mit dem Semantic Model und die Reporting-Ebene mit Reports und Apps. An dieser Struktur messen wir jede der drei Methoden. Sie zeigt am klarsten, was eine Methode leistet und was sie offen lässt.

Eine Vorbemerkung zur Einordnung: Wir behandeln in dieser Serie bewusst drei Wege getrennt, also Deployment Pipelines, die rein Git-basierte Methode und das fabric-cicd Framework. Das ist eine didaktische Entscheidung. Microsoft führt die beiden Git-Wege in der Dokumentation eng beieinander und kennt insgesamt vier Optionen, inklusive eines ISV-Szenarios. Für die Methodenwahl ist die Dreiteilung trotzdem der schärfere Schnitt, weil sich Skill-Profil, Release-Mechanik und Verantwortung deutlich unterscheiden.

Das Grundprinzip ist schnell erklärt. Sie definieren Stages, standardmäßig drei: Development, Test und Production. Konfigurierbar sind zwischen zwei und zehn Stages, deren Anzahl und Reihenfolge beim Anlegen festgelegt werden und sich danach nicht mehr ändern lassen. Jede Stage ist mit einem eigenen Workspace verknüpft. Wenn Sie einen Stand weiterreichen, kopiert Fabric die Items von der Quell- in die Ziel-Stage.

Den Kern bildet das Pairing. Items werden zwischen den Stages nicht einfach kopiert, sondern dauerhaft verknüpft. Ein Bericht in DEV wird mit dem zugehörigen Bericht in TEST verbunden, sodass beim nächsten Weiterreichen der bestehende Stand aktualisiert wird statt einer neuen Kopie. Die Zuordnung läuft über interne Item-Referenzen, nicht über die Namen. Eine Umbenennung bricht das Pairing deshalb nicht.

Für die Prozess-Ebene überträgt die Pipeline Notebooks, Pipelines und die Hülle des Lakehouse. Damit die Items in der Zielumgebung nicht weiter gegen DEV laufen, müssen Verbindungen und Referenzen umgehängt werden. Dafür gibt es zwei Mechanismen.

Die Deployment Rules überschreiben Werte pro Stage zum Zeitpunkt des Deployments, etwa eine andere Datenbankverbindung in PROD als in DEV. Sie sind eine Eigenschaft der Pipeline und greifen nur beim Weiterreichen. Mit Deployment Rules lässt sich keine Code-Parametrisierung umsetzen. Deployment Rules haben ein stark begrenztes Set an unterstützten Items. Sie sind nützlich um das Standard Lakehouse eines Notebooks oder die Lakehouse-Zuordnung eines Semantic Models umzuhängen. Die Variable Libraries setzen an einer anderen Stelle an. Eine Variable Library ist ein eigener Konfigurationsspeicher im Workspace, den andere Items zur Laufzeit auslesen. Sie hält pro Stage ein eigenes Wertepaket vor, von dem je Stage genau eines aktiv ist. Statt eine Verbindung in jedem Item einzeln zu pflegen, hinterlegen Sie sie einmal zentral und verweisen aus den Items darauf. Die Library ist selbst ein deploybares Item und wandert mit ihren Wertepaketen durch die Pipeline. Die beiden Mechanismen schließen sich nicht aus und werden oft kombiniert.

Auf der Modell- und Reporting-Ebene nimmt die Methode dem Team am meisten ab. Wird ein Bericht weitergereicht, findet er in der Zielstage automatisch sein passendes Semantic Model, und das Modell wiederum die passende Lakehouse, sofern die Deployment Rules korrekt gesetzt sind. Dieses automatische Pairing erspart Nacharbeit, die bei den Git-basierten Methoden manuell oder über Parameter anfällt.

Der stärkste Vorzug ist die niedrige Einstiegshürde. Kein Code, kein DevOps-Wissen, kein zusätzliches Werkzeug. Ein BI-Team betreibt den Prozess vollständig selbst. Für Teams, die Items bisher von Hand zwischen Workspaces verschoben haben, ist das ein spürbarer Fortschritt.

Hinzu kommt das Tempo. Innerhalb weniger Stunden steht eine funktionierende Trennung von Entwicklung, Test und Produktion. Das automatische Pairing zwischen Bericht und Semantic Model erledigt dabei einen großen Teil der Arbeit, die andere Methoden dem Team aufbürden.

Die Grenzen zeigen sich mit der Zeit und liegen in dem, was die Methode strukturell nicht leisten kann. Ohne Git-Anbindung gibt es keine echte Versionierung der Item-Stände. Es bleibt unklar, wer wann was geändert hat, und es fehlt die Historie, auf die man im Zweifel zurückgreifen könnte. Eine Git-Anbindung zur Code-Versionierung ist zwar möglich, aber für die Promotion zwischen den Stages bleibt Git irrelevant. Es interagiert nicht mit den Pipelines.

Damit fehlen auch Code-Reviews. Änderungen an DAX-Measures, an Power-Query-Logik oder an Notebooks lassen sich nicht strukturiert prüfen, bevor sie weiterwandern. Eine eingebaute Testautomatisierung gibt es ebenfalls nicht. Die Methode ist linear auf die Abfolge der Stages ausgelegt und kennt keine parallelen Entwicklungszweige.

Für die Methodenwahl zählt vor allem die strukturelle Folge. Mit Deployment Pipelines bleibt die Kontrolle im BI-Team. Das ist oft gewollt und in vielen Situationen richtig. Sie koppeln Ihre Fähigkeit zur Plattform-Entwicklung damit allerdings an das, was Microsoft im Portal abbildet.

Bei Wachstum zeigt sich die Grenze früh. Sobald zwei oder drei Teams parallel an unterschiedlichen Use Cases arbeiten, gerät die lineare Stage-Logik unter Druck. Features in unterschiedlichen Reifegraden lassen sich schwer abbilden, und es entsteht schnell ein Wildwuchs an Workspaces ohne gemeinsame Standards. Spätestens dann lohnt der Blick auf eine Git-Anbindung, idealerweise bevor die Teams völlig unabhängig voneinander arbeiten.

Ideal sind die Deployment Pipelines deshalb für ein einzelnes Team in einer Power-BI-zentrierten Umgebung, das einen schnellen Einstieg ohne DevOps-Overhead sucht. Das ist der typische Startpunkt vieler erfolgreicher Fabric-Projekte und eine legitime Wahl, solange der spätere Wachstumspfad mitgedacht wird.

Fabric Deployment Pipelines sind die pragmatischste Methode, um schnell zu einer sauberen DEV-TEST-PROD-Trennung zu kommen. Für ein einzelnes BI-Team sind sie häufig die beste Wahl, weil die Investition in einem gesunden Verhältnis zum Risiko steht.