Continuous Integration und Continuous Delivery (CI/CD) sind zentrale Praktiken in der agilen Entwicklung, die den Softwarebereitstellungsprozess automatisieren und optimieren. Im Kern beinhaltet CI/CD das automatische Integrieren von Codeänderungen in ein gemeinsames Repository, das kontinuierliche Testen dieser Änderungen und deren zuverlässige, wiederholbare Bereitstellung in der Produktionsumgebung. Dieser automatisierte Workflow minimiert nicht nur das Risiko von Integrationsfehlern, sondern stellt auch sicher, dass neue Features, Fehlerbehebungen und Verbesserungen schnell und konsistent veröffentlicht werden.
Bei der Entwicklung in Microsoft Fabric lassen sich diese Vorteile dank Deployment Pipelines und Git-Integration auf viele Weisen ausschöpfen. Erfahren sie in diesem Blog-Beitrag wie sie Deployment Pipelines verwenden können, um veränderte Inhalte von einer Entwicklungs- oder Testumgebung auf eine produktive Umgebung zu bringen, und wie Git die Versionierung und Zusammenarbeit bei der Entwicklung erleichtert.
Continuous Integration
In Microsoft Fabric können Workspaces direkt mit einem Git-Repository verbunden werden, entweder via Azure DevOps oder GitHub, wodurch Entwicklerteams gemeinsam an verschieden Version von Workspace Artefakte (Reports, Dashboards, Warehouses, semantische Modelle, Notebooks, Pipelines, etc.) arbeiten können. Für jeden Workspace der mit einem Git-Repository verknüpft ist, werden Veränderungen automatisch nachverfolgt, wodurch das Review und die Synchronisation von Updates direkt aus dem Fabric UI vereinfacht wird. Arbeiten jedoch mehrere Entwickler gemeinsam an einem Workspace auf dem Main-Branch, so sind alle Entwickler von Änderungen direkt betroffen.
Hier kommt das Branching ins Spiel. Z.B. lassen sich direkt über das Microsoft Fabric UI Feature-Branches erstellen. Hierbei wird der gesamte Workspace aus dem Main-Branch in einen Feature-Workspace geklont und Entwickler können isoliert an ihren Features arbeiten. Feature-Branch und Feature-Workspace stehen dabei immer in-sync. Wie bei Git üblich, lassen sich diese Feature-Branches in den Main-Branch (und somit den Main-Workspace) per Pull-Request einfügen. Weiter lassen sich viele der CI-Prozess dank der Git-Integration-APIs automatisieren und in bestehende DevOps-Abläufe, z.B. in Azure DevOps, einfügen.
Continuous Delivery
Um Microsoft Fabric Workspaces und darin enthaltene Artefakte auszurollen gibt es verschiedene Möglichkeiten. In einer klassischen Infrastruktur mit drei Umgebungen – Entwicklung, Test und Produktion – kommen Git oder Deployment-Pipelines zum Einsatz. Ein reiner Git-Deploymentprozess nutzt verschiedene Main-Branches, wobei jede Umgebung ihren eigenen Main-Branch besitzt. Das Deployment von Entwicklung nach Test und von Test nach Produktion geschieht via Pull-Request.
Alternativ kann das Deployment auch per Fabric Deployment-Pipelines durchgeführt werden. Jeder Umgebung wird dabei eine Pipeline-Stufe mit einem dedizierten Workspace hinzugefügt. Zudem gilt es zu definieren, welche Artefakte einer Umgebung mit bestimmten Artefakten einer anderen Umgebung verbunden sind. Durch dieses ausdrückliche Pairing müssen die Namen der Workspace Artefakte pro Umgebung nicht zwingend miteinander übereinstimmen. Ähnlich wie Git, bieten auch die Microsoft Fabric Deployment-Pipelines die Möglichkeit, geänderte Artefakte zu identifizieren und nur diese auszurollen. Zudem lassen sich Deployment-Regeln erstellen, die Workspace-Artefakte für die Zielumgebung anpassen. Auf diese Weise können z.B. Quellverbindungen oder Abfrage-Parameter angepasst werden. Dank REST APIs lassen sich Deployment-Pipelines automatisieren und in grössere CI/CD Prozesse einbinden. Viele der für Deployment-Pipelines unterstütze Artefakte sind noch im Preview und die Liste der unterstützen Artefakte ist noch nicht vollständig.
Hinweis: Beim Verwenden von Git wie auch von Pipelines, werden lediglich Metadaten inklusive Konfigurationen und Verlinkungen (z.B. Dashbord zu semantischem Modell) geklont; die Daten selbst verbleiben im OneLake und müssen nach jedem Deployment von Backend-Objekten neu geladen werden. Ausgenommen sind Notebooks, semantische Modelle oder Reports/Dashboards – hier reicht eine Aktualisierung des semantischen Modelles aus.
Ways of Working
Bei IT-Logix geben wir folgende Empfehlung zum Entwickeln in Microsoft Fabric mithilfe von CI/CD Prozessen ab. Dabei spielt vor allem die Grösse des Entwicklerteams sowie das vorhanden technologische Knowhow eine massgebende Rolle.
Szenario 1 – Microsoft Fabric Deployment Pipelines, mit einem Main-Branche für CI-Prozesse in der Entwicklungsumgebung.
Richtlinien:
- Drei Workspaces für drei Umgebungen (Entwicklung-Test-Produktion)
- Implementierung von neue Features auf der Entwicklungsumgebung
- Änderungen werden direkt im Main-Branch der Entwicklungsumgebung vorgenommen. Workspace Artefakte werden per Deployment-Pipeline von Entwicklung nach Test und von Test nach Produktion verschoben
Vorteile:
- Einfach zu implementieren
- Kurze Entwicklung und Deployment Zyklen, kein Overhead von Code-Reviews
- Ideal für kleine Teams mit 1 bis 3 Entwicklern
- Wenig Git-Knowhow notwendig – kein Branching, keine Pull-Requests
Nachteile:
- Da das Entwicklerteam stets auf derselben Codebase arbeitet, erfordert dieses Szenario eine enge Abstimmung. Wächst das Team oder stockt die Kommunikation, empfiehlt sich die Nutzung von Feature-Branches. So lassen sich einzelne Entwicklungsschritte isolieren und Code-Review-Prozesse einführen.
Szenario 2 – Microsoft Fabric Deployment Pipelines, mit Git-Branches
Richtlinien:
- Drei Workspaces für drei Umgebungen (Entwicklung-Test-Produktion)
- Implementierung von neue Features auf der Entwicklungsumgebung
- Verwaltung des Git-Repository in Azure DevOps
- Nur für die Entwicklungsumgebung werden Änderungen via Git verfolgt und neue Features werden auf Feature-Branches entwickelt
- Die Entwicklung läuft dabei wie folgt ab:
- Auf dem Entwicklungs-Workspace werden keine Entwicklungen direkt durchgeführt; dieser dient dem Konsolidieren der neu entwickelten Features aus den Feature-Branches. Dieser Workspace ist in-sync mit dem Main-Git-Branch.
- Die Entwicklung jedes neuen Features oder das Beheben eines Fehlers geschieht in einem separaten Branch mit seinem eigenen Workspace. Feature-Branch und Workspace werden mit Fabric’s Branch-Off Funktionalität erstellt. Um die Branch-Off Funktion nutzen zu können brauch der User die Rechte, um Workspace anzulegen.
- Sind Features fertig entwickelt oder Fehler behoben, werde diese via Pull-Request in den Main-Branch der Entwicklungsumgebung eingefügt. Der Feature-Workspace kann nach erfolgreichem Zusammenführen gelöscht werden
- Workspace Artefakte werden per Deployment-Pipeline von Entwicklung nach Test und von Test nach Produktion verschoben. Feature-Branches werden nicht in die Deployment-Pipelines integriert
- Rollback/Restore:
- Der letzte stabile Zustand des Codes muss im Git-Repository identifiziert und in den Main-Branch eingefügt werden.
- Deployment-Pipelines setzen Test- und Produktions-Workspaces auf den stabilen Zustand zurück
Vorteile:
- Durch die Isolation der Entwicklungsschritte werden Feature-Releases übersichtlicher und Code-Reviews sicherer
- Ideal für mittelgrosse bis grosse Teams ab 4 Entwicklern
Nachteile:
- Komplexer als Szenario 1
- Längere Entwicklungs- und Deploymentzyklen
- Erfordert vertieftes Git- und Deployment-Pipeline-Knowhow
- Entwickler müssen spezifische Entwicklungsrichtlinien befolgen
Szenario 3 – reines Git-Deployment
Richtlinien:
- Drei Workspaces für drei Umgebungen (Entwicklung-Test-Produktion)
- Jeder dieser Workspaces hat einen entsprechenden Git-Branch
- Für die Branches von Entwicklung, Test und Produktion sind direkte Commits nicht erlaubt
- Die einzige Möglichkeit, Neuentwicklungen einzubinden, ist per Feature-Branches und deren Workspaces via Pull-Requests über den Entwicklungs-Branch/Workspace
Vorteile:
- Durch die Isolation der Entwicklungsschritte werden Feature-Releases übersichtlicher und Code-Reviews sicherer
- Ideal für mittelgrosse bis grosse Teams ab 4 Entwicklern
- Schnellere Entwicklungs- und Deploymentzyklen als Szenario 2 (wenn Git-Knowhow vorhanden ist)
Nachteile:
- Etwas komplexer als Szenario 1
- Erfordert vertieftes Git-Knowhow
- development/ deployment cycles are not as fast as in Scenario 1
- Entwickler müssen spezifische Entwicklungsrichtlinien befolgen
Fazit
Fabric bietet eine Vielzahl an Möglichkeiten CI/CD Prozesse zu implementieren. Sei dies rein per Git-Integration oder in einer beliebigen Kombination aus Git und Fabric Deployment-Pipelines. Die Größe des Entwicklerteams und dessen technologisches Wissen über Tools wie Git oder Deployment-Pipelines bestimmen maßgeblich, wie CI/CD implementiert werden sollte. Wenn Sie Ihre Entwicklungsprozesse robuster gestalten und teilweise automatisieren wollen, stehen wir Ihnen mit unserer Expertise gerne zur Verfügung.
Buchen Sie Ihre kostenlose Fabric in an Hour oder holen Sie sich das kostenlose Video unseres Webinars zu Microsoft Fabric.
Weitere Angebote rund um das Thema Microsoft Fabric finden Sie hier.