Microsoft Fabric CI/CD: Git, Deployment Pipelines, APIs und IaC kombinieren

CI/CD in Microsoft Fabric ist längst mehr als die Frage, ob ein Workspace mit Git verbunden wird. Git Integration, Deployment Pipelines, REST APIs, Fabric CLI, Variable Libraries, Terraform und fabric-cicd decken unterschiedliche Teile des Application Lifecycle Managements ab. Wer sie wie austauschbare Deployment-Werkzeuge behandelt, baut schnell einen Prozess, der zwar automatisiert aussieht, aber spätestens zwischen Dev, Test und Prod auseinanderläuft.

Microsoft Fabric bietet inzwischen einen ziemlich vollständigen Werkzeugkasten für Continuous Integration und Continuous Delivery. Dazu gehören die Git-Integration mit Azure DevOps oder GitHub, Fabric Deployment Pipelines, REST APIs, die Fabric CLI, Variable Libraries sowie Terraform und die Python-Bibliothek fabric-cicd. Die zentrale Architekturfrage lautet deshalb nicht mehr „Welches CI/CD-Tool nehmen wir?“, sondern „Welche Aufgabe übernimmt welches Werkzeug?“ Genau diese Trennung entscheidet darüber, ob aus einzelnen Automatisierungen ein belastbares Betriebsmodell wird.

Microsoft Fabric CI/CD ist eine Architekturentscheidung

Für ein klassisches Dev-Test-Prod-Modell müssen mehrere Aufgaben voneinander getrennt werden: Quellcode und Versionierung, Bereitstellung der Fabric-Umgebungen, Deployment der eigentlichen Fabric-Artefakte, umgebungsspezifische Konfiguration sowie Orchestrierung, Tests und Freigaben. Kein einzelnes Fabric-Werkzeug deckt diese Aufgaben vollständig ab.

Microsoft unterscheidet inzwischen selbst mehrere CI/CD-Modelle: Git-basierte Deployments mit getrennten Branches, trunk-basierte Deployments über Fabric Item APIs beziehungsweise fabric-cicd, Fabric Deployment Pipelines und spezielle Multi-Workspace-Modelle für ISVs. Hybride Ansätze sind ausdrücklich vorgesehen.

Für die Praxis ist eine andere Sicht noch hilfreicher:

Baustein	Hauptaufgabe	Typische Rolle
Git Integration	Versionierung und Zusammenarbeit	Source Control / Continuous Integration
Deployment Pipelines	Promotion zwischen Fabric-Workspaces	Fabric-native Continuous Delivery
REST APIs / Fabric CLI	Automatisierung und Orchestrierung	Glue Layer
Terraform	Bereitstellung der Plattform	Infrastructure as Code
fabric-cicd	Deployment von Fabric-Item-Definitionen	Code-first Continuous Delivery
Variable Library	Umgebungsabhängige Konfiguration	Configuration as Code

Die Werkzeuge ergänzen sich. Genau deshalb ist etwa die häufig gestellte Frage „Deployment Pipelines oder Git?“ meistens falsch gestellt.

Git Integration: Source Control statt vollständiges Deployment

Die Git-Integration verbindet einen Fabric-Workspace mit Azure DevOps oder GitHub. Änderungen an unterstützten Fabric-Artefakten werden dadurch versionierbar, können über Branches und Pull Requests geprüft und anschließend wieder mit einem Workspace synchronisiert werden.

Damit löst Git einen zentralen Teil von Continuous Integration: Teams erhalten Historie, Review-Prozesse, Branching, Rollback-Möglichkeiten und eine technische Grundlage für automatisierte Builds und Tests.

Git beantwortet aber nicht automatisch die Frage, wie ein freigegebener Stand kontrolliert nach Test und Produktion gelangt.

Ein mögliches Modell besteht darin, Dev, Test und Prod jeweils über eigene Hauptbranches mit eigenen Workspaces zu verbinden. Nach einer Freigabe werden Änderungen über Branches weitergereicht und die Zielworkspaces mit den Fabric Git APIs aktualisiert. Microsoft ordnet dieses Modell vor allem Teams zu, die Git als alleinige Source of Truth und Gitflow mit mehreren Stage-Branches einsetzen.

Das funktioniert, bringt aber zusätzliche Branch- und Synchronisationslogik mit sich. Für viele Teams ist deshalb ein Modell mit einem zentralen Main-Branch und separater Deployment-Logik einfacher.

Deployment Pipelines: Fabric-native Promotion von Dev nach Test und Prod

Fabric Deployment Pipelines verfolgen einen anderen Ansatz. Git wird typischerweise bis in die Entwicklungsumgebung eingesetzt. Anschließend werden Artefakte direkt von Workspace zu Workspace über Dev, Test und Prod bewegt.

Damit ist nicht mehr Git selbst das Deployment-Medium für jede Stage. Stattdessen übernimmt Fabric die Promotion zwischen den Umgebungen. Deployment Rules, Autobinding, Änderungsvergleiche und Deployment-Historie machen diesen Weg insbesondere für Teams attraktiv, die möglichst viel Lifecycle-Management innerhalb von Fabric halten möchten. Die Deployment-Pipeline-APIs erlauben trotzdem eine Einbindung in Azure DevOps oder GitHub Workflows.

Das Modell ist besonders sinnvoll, wenn die vorhandenen Deployment-Regeln und Bindings die benötigten Umgebungsunterschiede abdecken.

Es hat aber Grenzen. Ein wichtiges aktuelles Beispiel betrifft die Netzwerksicherheit: Fabric Deployment Pipelines werden derzeit nicht für Workspaces mit Inbound Access Protection unterstützt. Bei stärker abgeschotteten Plattformarchitekturen muss diese Einschränkung bereits vor der Entscheidung für das Deployment-Modell berücksichtigt werden.

Terraform und fabric-cicd lösen zwei unterschiedliche Probleme

Für stärker automatisierte Fabric-Plattformen ist eine Trennung besonders wichtig: die zwischen Control Plane und Data Plane.

Zur Control Plane gehören vergleichsweise stabile Plattformressourcen wie Workspaces, Kapazitäten, Verbindungen, Zugriffsrechte, Domains und die Git-Anbindung. Genau hierfür eignet sich Terraform.

Zur Data Plane gehören dagegen die Fabric-Inhalte, die sich mit den Entwicklungszyklen ständig ändern: Notebooks, Lakehouses, Warehouses, Pipelines, Dataflows, semantische Modelle, Reports oder Variable Libraries. Diese Inhalte lassen sich über Git und beispielsweise fabric-cicd zwischen Umgebungen bewegen. Microsoft verwendet genau diese Trennung inzwischen selbst in seiner End-to-End-Referenz für automatisierte Fabric-Deployments.

Daraus ergibt sich eine einfache Regel: Terraform baut und kontrolliert die Bühne. fabric-cicd beziehungsweise Deployment Pipelines bewegen den Inhalt über diese Bühne. Der Versuch, beide Aufgaben in ein einziges Werkzeug zu pressen, erhöht dagegen unnötig die Komplexität.

Was fabric-cicd zusätzlich bringt

fabric-cicd ist eine Open-Source-Python-Bibliothek für code-first Deployments von Fabric-Item-Definitionen. Sie abstrahiert die zugrunde liegenden Fabric REST APIs und kann unter anderem aus Git heraus Fabric-Artefakte erstellen beziehungsweise aktualisieren. Sie lässt sich beispielsweise in Azure Pipelines oder GitHub Actions integrieren. Besonders interessant wird fabric-cicd, wenn Git tatsächlich die Source of Truth bleiben soll.

Umgebungsspezifische Werte können beim Deployment parametrisiert werden. Ein Notebook kann dadurch in Dev auf das Dev-Lakehouse und nach der Promotion in Test auf das entsprechende Test-Lakehouse zeigen. Auch Artefakte, die aus Git entfernt wurden, können beim Deployment aus der Zielumgebung entfernt werden, sodass Workspace und Repository nicht unkontrolliert auseinanderlaufen.

Für Pro-Code-Teams entsteht damit ein anderes Betriebsmodell als mit Deployment Pipelines:

Main Branch → Build/Test → fabric-cicd → Test → Freigabe → fabric-cicd → Prod

Die Zielworkspaces müssen dabei nicht selbst mit Git verbunden sein. Der freigegebene Git-Stand wird durch die Deployment-Automatisierung in die jeweiligen Umgebungen übertragen. Dieses Muster passt besonders gut zu trunk-basierten Entwicklungsmodellen.

REST APIs und Fabric CLI sind der Glue Layer

Zwischen diesen Bausteinen bleiben fast immer Aufgaben übrig: einen Workspace mit Git synchronisieren, ein Deployment anstoßen, einen Job starten, einen Status prüfen oder einen Post-Deployment-Schritt ausführen. Hier kommen die Fabric REST APIs und die Fabric CLI ins Spiel.

Die REST APIs bilden die technische Grundlage für viele Fabric-CI/CD-Funktionen und ermöglichen programmatischen Zugriff auf Workspaces, Items, Definitionen, Zugriffsrechte, Jobs und weitere Plattformobjekte. Die Fabric CLI stellt darauf eine skriptbare, dateisystemähnliche Kommandozeilenschnittstelle bereit, die sich unter anderem in GitHub Actions und Azure DevOps einsetzen lässt. Diese Werkzeuge sollten deshalb nicht als dritter konkurrierender Deployment-Ansatz verstanden werden.

APIs und CLI verbinden die einzelnen Schritte zu einem automatisierten Prozess.

Variable Libraries lösen das Konfigurationsproblem

Einer der häufigsten Gründe für instabile Dev-Test-Prod-Prozesse sind fest eingetragene Workspace-IDs, Lakehouse-IDs, URLs oder andere umgebungsspezifische Parameter. Genau hier setzen Fabric Variable Libraries an.

Eine Variable Library kann mehrere Value Sets enthalten, beispielsweise für Dev, Test und Prod. In jedem Workspace beziehungsweise jeder Stage ist ein Value Set aktiv. Die Bibliothek kann mit Git versioniert und über Deployment Pipelines bereitgestellt werden. Die Auswahl des aktiven Value Sets bleibt dabei je Stage unabhängig. Damit wird Konfiguration selbst zu einem kontrollierbaren Bestandteil des Lifecycle Managements.

Das Ziel sollte sein, dass sich die fachlich identische Lösung zwischen den Stages bewegt, während die Umgebungskonfiguration außerhalb der eigentlichen Business-Logik aufgelöst wird.

Für viele professionelle Fabric-Umgebungen ergibt sich daraus ein mehrschichtiges Zielbild.

1. Terraform verwaltet die stabile Plattform.

Workspaces, Rollen, Verbindungen, Git-Anbindungen und weitere Infrastruktur werden deklarativ beschrieben. Änderungen an der Plattform sind dadurch nachvollziehbar und Drift kann sichtbar gemacht werden.

2. Git ist die Entwicklungs- und Review-Basis.

Entwickler arbeiten isoliert, Änderungen werden versioniert und über Pull Requests zusammengeführt. Der freigegebene Main-Branch repräsentiert den für ein Deployment vorgesehenen Stand.

3. Die Continuous-Delivery-Strategie wird bewusst gewählt.

Fabric-native Teams können ab Dev Deployment Pipelines verwenden. Teams mit Git als konsequenter Source of Truth können die Artefakte stattdessen über fabric-cicd oder Item APIs aus dem Repository in Test und Prod deployen. Beide Ansätze sind legitim – entscheidend ist, dass die Source of Truth eindeutig definiert bleibt.

4. Variable Libraries und Parameterisierung trennen Konfiguration vom Inhalt.

Dev-, Test- und Prod-spezifische Werte werden nicht unkontrolliert in Artefakte eingebaut.

5. REST APIs oder Fabric CLI orchestrieren den Prozess.

Synchronisation, Deployments, Tests, Refreshes oder weitere Post-Deployment-Aktivitäten werden automatisiert angestoßen und überprüft.

6. Zwischen den Stages liegen echte Quality Gates.

Ein technisch erfolgreiches Deployment ist noch keine fachliche Freigabe. Smoke Tests, Datenprüfungen, Regressionstests und je nach Artefakt auch visuelle beziehungsweise semantische Prüfungen gehören zwischen Test und Produktion.

So entsteht nicht nur eine Deployment-Automatisierung, sondern ein Betriebsmodell.

Welcher CI/CD-Ansatz passt wann?

Für die Architekturentscheidung lassen sich vier typische Situationen unterscheiden.

Situation	Sinnvolle Kombination
Kleines bis mittleres Fabric-Team, möglichst wenig eigene Deployment-Logik	Git Integration in Dev + Deployment Pipelines + Variable Library
Pro-Code-Team, Git als konsequente Source of Truth, trunk-based	Git + fabric-cicd + APIs/CLI + Variable Library
Plattformteam mit automatisiertem Environment-Provisioning	Terraform + Git + fabric-cicd oder Deployment Pipelines + APIs
Viele gleichartige Kunden-/Tenant-Workspaces	Git + Item APIs/fabric-cicd + Parameterisierung + Terraform

Die Entscheidung sollte also nicht mit dem Tool beginnen. Sie beginnt mit vier Fragen: Wo liegt die Source of Truth? Wie bewegen sich Artefakte zwischen den Stages? Wo liegt die Umgebungskonfiguration? Und wer beziehungsweise was darf ein Deployment ausführen? Erst danach sollte die Werkzeugkombination festgelegt werden.

Git Integration und Deployment Pipelines sind keine Konkurrenten

Gerade dieser Punkt sorgt in Fabric-Projekten häufig für Missverständnisse.

Git löst primär das Problem der gemeinsamen Entwicklung und Versionierung. Deployment Pipelines lösen primär das Problem der kontrollierten Promotion zwischen Fabric-Umgebungen.

Deshalb kann ein sehr pragmatischer Aufbau so aussehen:

Feature Branch → Pull Request → Main → Dev Workspace → Deployment Pipeline → Test → Deployment Pipeline → Prod

Git bleibt bis Dev die Entwicklungsbasis. Ab dort übernimmt die Fabric Deployment Pipeline.

Ein anderes Team kann sich bewusst dafür entscheiden, auch Test und Prod ausschließlich aus einem freigegebenen Git-Stand zu erzeugen. Dann sieht derselbe Abschnitt eher so aus:

Feature Branch → Pull Request → Main → fabric-cicd → Test → Freigabe → fabric-cicd → Prod

Beides kann richtig sein. Problematisch wird es erst, wenn gleichzeitig Git, Workspaces und Deployment Pipelines als unabhängige Source of Truth behandelt werden.

CI/CD muss die Security-Architektur berücksichtigen

Ein CI/CD-Modell darf nicht losgelöst vom Fabric-Sicherheitsmodell entstehen. Automatisierungsidentitäten sollten klar von persönlichen Benutzerkonten getrennt werden. Fabric unterstützt Service Principals für automatisierte Szenarien, insbesondere in Verbindung mit Azure DevOps. Für die automatisierte Git-Anbindung mit Service Principal dokumentiert Microsoft derzeit Azure DevOps; die entsprechende programmgesteuerte Verbindung eines Workspaces mit GitHub über Service Principal wird im End-to-End-Szenario noch nicht unterstützt. Secrets gehören nicht in das Repository. Berechtigungen sollten auf das notwendige Maß begrenzt sein.

Auch Netzwerkregeln können die Architektur beeinflussen. Bei Outbound Access Protection ist Git standardmäßig blockiert und muss für den jeweiligen Workspace explizit durch einen Administrator zugelassen werden. Bei Inbound Access Protection sind Git-Operationen einschließlich der Git APIs an die erlaubten Netzwerke gebunden; Deployment Pipelines sind für entsprechend geschützte Workspaces aktuell nicht unterstützt.

Wer Security erst nach dem Aufbau der Pipeline betrachtet, riskiert deshalb einen kompletten Umbau des Release-Prozesses.

Die häufigsten CI/CD-Anti-Patterns in Fabric

Einige Muster sind besonders problematisch:

• Änderungen direkt in Produktion vorzunehmen und anschließend zurück nach Git zu übertragen.

• Dev, Test und Prod in einem gemeinsamen Workspace abzubilden.

• Deployment Pipelines als Ersatz für Versionskontrolle zu behandeln.

• Terraform gleichzeitig als Plattform- und Content-Deployment-Werkzeug erzwingen zu wollen.

• Git-Branches für jede Stage einzuführen, ohne eine eindeutige Source-of-Truth-Regel zu definieren.

• Workspace-IDs, Connection-IDs oder Lakehouse-IDs direkt in Artefakten zu hinterlegen.

• Secrets oder Service-Principal-Credentials im Repository zu speichern.

• Davon auszugehen, dass jedes Fabric-Item dieselben Git-, Deployment- und API-Funktionen unterstützt.

• Deployment-Erfolg mit fachlicher Produktionsfreigabe gleichzusetzen.

Gerade der letzte Punkt wird mit zunehmender Automatisierung wichtiger: Je einfacher technische Deployments werden, desto bewusster müssen Tests und Freigaben gestaltet werden.

Entscheidungsmodell für Microsoft Fabric CI/CD

Für neue Fabric-Plattformen würden wir die Entscheidung deshalb in dieser Reihenfolge treffen:

Source of Truth festlegen.

Soll Git der verbindliche Stand der Lösung sein oder soll nach Dev der Fabric-Workspace den Release-Zustand bestimmen?

Control Plane und Data Plane trennen.

Stabile Plattformobjekte gehören in ein Infrastructure-as-Code-Modell. Häufig veränderte Fabric-Artefakte benötigen einen eigenen Release-Prozess.

Deployment-Modell auswählen.

Deployment Pipelines sind stark für Fabric-native Promotion. fabric-cicd und Item APIs sind stark für code-first und Git-zentrierte Modelle.

Konfiguration externalisieren.

Variable Libraries und Deployment-Parameter verhindern, dass Dev-, Test- und Prod-spezifische Werte unkontrolliert im Content landen.

Automatisierungsidentität und Netzwerkmodell prüfen.

Service Principals, Berechtigungen sowie Inbound- und Outbound-Schutz können die Werkzeugwahl beeinflussen.

Quality Gates definieren.

Test und Prod benötigen nicht nur technische Deployments, sondern überprüfbare Freigabekriterien.

Wer diese Reihenfolge einhält, muss CI/CD nicht um einzelne Fabric-Funktionen herum bauen. Stattdessen entsteht ein Lifecycle-Modell, in das neue Werkzeuge und zusätzliche Artefakttypen später eingeordnet werden können.

---

Fazit: Nicht ein Tool wählen, sondern Verantwortlichkeiten trennen

Microsoft Fabric verfügt inzwischen über fast alle Bausteine, die für professionelle CI/CD-Prozesse benötigt werden. Die Herausforderung liegt weniger darin, noch mehr Automatisierung hinzuzufügen, sondern die vorhandenen Werkzeuge sauber voneinander abzugrenzen.

Git Integration versioniert. Deployment Pipelines promoten. Terraform provisioniert. fabric-cicd deployt code-first. Variable Libraries konfigurieren. APIs und CLI orchestrieren.

Für viele Unternehmen wird deshalb weder „nur Deployment Pipelines“ noch „nur Git“ die beste Architektur sein. Entscheidend ist eine Kombination, bei der Source of Truth, Deployment-Verantwortung, Konfiguration, Security und Quality Gates eindeutig geregelt sind.

---

Nächste Schritte

Wenn ihr eure Microsoft-Fabric-Plattform von Anfang an mit einem belastbaren Dev-Test-Prod- und CI/CD-Modell aufbauen wollt, können wir diese Architektur gemeinsam im Microsoft Fabric Kick Start entwickeln und auf eure Governance-, Security- und Betriebsanforderungen abstimmen.