Freigeben über

Wählen Sie die beste Fabric CI/CD-Workflowoption für Sie aus.

Ziel dieses Artikels ist es, Fabric-Entwicklern verschiedene Optionen zum Erstellen von CI/CD-Prozessen in Fabric basierend auf gängigen Kundenszenarien zu präsentieren. Dieser Artikel konzentriert sich mehr auf die kontinuierliche Bereitstellung (CD) des CI/CD-Prozesses. Eine Diskussion zum Teil "Kontinuierliche Integration (CI)" finden Sie unter "Manage Git branches".

In diesem Artikel werden zwar mehrere verschiedene Optionen beschrieben, viele Organisationen haben jedoch einen Hybridansatz.

Voraussetzungen

Für den Zugriff auf das Feature „Bereitstellungspipelines“ müssen Sie die folgenden Bedingungen erfüllen:

Entwicklungsprozess

Der Entwicklungsprozess ist in allen Bereitstellungsszenarien identisch und unabhängig davon, wie neue Updates in der Produktion veröffentlicht werden. Wenn Entwickler mit der Quellcodeverwaltung arbeiten, müssen sie in einer isolierten Umgebung arbeiten. In Fabric kann diese Umgebung entweder eine IDE auf Ihrem lokalen Computer (z. B. Power BI Desktop oder VS Code) oder ein anderer Arbeitsbereich in Fabric sein. Informationen zu den verschiedenen Überlegungen für den Entwicklungsprozess finden Sie in Git-Verzweigungen verwalten

Diagramm, das zeigt, wie der Entwicklungsprozess funktioniert.

Releaseprozess

Der Veröffentlichungsprozess beginnt, sobald neue Updates abgeschlossen sind und die Pullanforderung (PR) in der gemeinsamen Verzweigung des Teams (z.B. Main, Dev usw.) zusammengeführt wird. Ab diesem Zeitpunkt gibt es verschiedene Optionen zum Erstellen eines Releaseprozesses in Fabric.

Option 1 – Git-basierte Bereitstellungen

Diagramm, das zeigt, wie die Git-basierte Bereitstellung funktioniert.

Mit dieser Option stammen alle Bereitstellungen aus dem Git-Repository. Jede Phase in der Releasepipeline verfügt über eine dedizierte primäre Verzweigung (im Diagramm sind diese Phasen Dev, Test und Prod), die den entsprechenden Arbeitsbereich in Fabric einspeist.

Sobald eine PR für den Dev Branch genehmigt und zusammengeführt wurde:

  1. Eine Releasepipeline wird ausgelöst, um den Inhalt des Dev-Arbeitsbereichs zu aktualisieren. Dieser Prozess kann auch eine Buildpipeline zum Ausführen von Komponententests enthalten, aber der tatsächliche Upload von Dateien erfolgt direkt vom Repository in den Arbeitsbereich mithilfe von Fabric Git-APIs. Möglicherweise müssen Sie andere Fabric-APIs für Vorgänge nach der Bereitstellung aufrufen, die bestimmte Konfigurationen für diesen Arbeitsbereich festlegen oder Daten aufnehmen.
  2. Anschließend wird eine PR für die Test-Verzweigung erstellt. In den meisten Fällen wird die PR mit einer Release-Verzweigung erstellt, die den Inhalt auswählen kann, um in die nächste Phase zu wechseln. Die PR sollte die gleichen Überprüfungs- und Genehmigungsprozesse wie jede andere in Ihrem Team oder Ihrer Organisation enthalten.
  3. Eine weitere Build- und Releasepipeline wird ausgelöst, um den Testarbeitsbereich mithilfe eines Prozesses zu aktualisieren, der dem im ersten Schritt beschriebenen Prozess ähnelt.
  4. Eine PR wird für Prod Branch erstellt, wobei ein Prozess verwendet wird, der dem in Schritt 2 beschriebenen Prozess ähnelt.
  5. Eine weitere Build- und Releasepipeline wird ausgelöst, um den Prod-Arbeitsbereich mithilfe eines Prozesses zu aktualisieren, der dem im ersten Schritt beschriebenen Prozess ähnlich ist.

Wann sollten Sie die Option #1 verwenden?

  • Wenn Sie Ihr Git-Repository als einzige Quelle der Wahrheit und den Ursprung aller Bereitstellungen verwenden möchten.
  • Wenn Ihr Team Gitflow als Branching-Strategie verwendet, einschließlich mehrerer primärer Zweige.
  • Der Upload aus dem Repository geht direkt in den Arbeitsbereich, da wir keine Buildumgebungen benötigen, um Dateien vor der Bereitstellung zu bearbeiten. Sie können dies ändern, indem Sie APIs aufrufen oder Elemente im Arbeitsbereich nach der Bereitstellung ausführen.

Option 2 – Git-basierte Bereitstellungen mit Buildumgebungen

Diagramm, das den Fluss der gitbasierten Bereitstellung mithilfe von Buildumgebungen zeigt.

Mit dieser Option stammen alle Bereitstellungen aus demselben Zweig des Git-Repositorys (Main). Jede Phase in der Releasepipeline verfügt über eine dedizierte Build- und Releasepipeline. Diese Pipelines können eine Buildumgebung verwenden, um Komponententests und Skripts auszuführen, die einige der Definitionen in den Elementen ändern, bevor sie in den Arbeitsbereich hochgeladen werden. Sie können z. B. die Datenquellenverbindung, die Verbindungen zwischen Elementen im Arbeitsbereich oder die Werte der Parameter ändern, um die Konfiguration für die richtige Phase anzupassen.

Sobald eine PR für die Dev Branch genehmigt und zusammengeführt wurde:

  1. Eine Buildpipeline wird ausgelöst, um eine neue Buildumgebung zu starten und Komponententests für die Entwicklungsstufe auszuführen. Anschließend wird eine Release-Pipeline ausgelöst, um den Inhalt in eine Build-Umgebung hochzuladen, dabei Skripts auszuführen, um einige der Konfigurationen zu ändern und die Konfiguration an die Dev-Stufe anzupassen. Dann werden die Update-Elementdefinitions-APIs von Fabric verwendet, um die Dateien in den Arbeitsbereich hochzuladen.
  2. Wenn dieser Prozess abgeschlossen ist, einschließlich der Erfassung von Daten und der Genehmigung von Release-Managern, können die nächsten Build und Release-Pipelines für die Testphase erstellt werden. Diese Phasen werden in einem Prozess erstellt, der dem im ersten Schritt beschriebenen ähnelt. Für die Testphase sind möglicherweise andere automatisierte oder manuelle Tests nach der Bereitstellung erforderlich, um zu überprüfen, ob die Änderungen für die Prod-Phase freigegeben werden können.
  3. Wenn alle automatisierten und manuellen Tests abgeschlossen sind, kann der Release-Manager die Build- und Release-Pipelines in die Prod-Phase genehmigen und starten. Da die Prod-Stufe normalerweise andere Konfigurationen als die Test-/Entwicklungsphasen aufweist, ist es wichtig, die Änderungen auch nach der Bereitstellung zu testen. Außerdem sollte die Bereitstellung eine erneute Erfassung von Daten basierend auf der Änderung auslösen, um potenzielle Verfügbarkeitseinschränkungen für Verbraucher zu minimieren.

Welche Komponenten können verwendet werden, um Option #2 zu implementieren?

  • Fabric-cicd – eine Python-Bibliothek , die für die Verwendung mit Microsoft Fabric-Arbeitsbereichen entwickelt wurde. Diese Bibliothek unterstützt Code-first Continuous Integration /Continuous Deployment (CI/CD)-Automatisierungen, um Arbeitsbereiche nahtlos in ein Bereitstellungsframework zu integrieren. Für ein vollständiges End-to-End-Beispiel folgen Sie unserem Lernprogramm "fabric-cicd" und "Azure DevOps".

Wann sollten Sie die Option #2 verwenden?

  • Wenn Sie Git als einzige Quelle der Wahrheit und den Ursprung aller Bereitstellungen verwenden möchten.
  • Wenn Ihr Team dem Trunk-basierten Workflow als Verzweigungsstrategie folgt.
  • Sie benötigen eine Buildumgebung (mit einem benutzerdefinierten Skript), um arbeitsbereichspezifische Attribute wie connectionId und lakehouseId vor der Bereitstellung zu ändern.
  • Sie benötigen eine Releasepipeline (benutzerdefiniertes Skript), um Elementinhalte von Git abzurufen und die entsprechende Fabric Item-API zum Erstellen, Aktualisieren oder Löschen von geänderten Fabric-Elementen aufzurufen.

Option 3 : Bereitstellen mithilfe von Fabric-Bereitstellungspipelines

Diagramm, das den Fluss der gitbasierten Bereitstellung mithilfe von Bereitstellungspipelines zeigt.

Mit dieser Option ist Git nur bis zur Entwicklungsstufe verbunden. In der Entwicklungsphase erfolgen Bereitstellungen direkt zwischen den Arbeitsbereichen von Dev/Test/Prod mithilfe von Fabric-Bereitstellungspipelines. Während das Tool selbst für Fabric intern ist, können Entwickler die Bereitstellungspipeline-APIs verwenden, um die Bereitstellung als Teil ihrer Azure-Releasepipeline oder eines GitHub-Workflows zu koordinieren. Diese APIs ermöglichen es dem Team, einen ähnlichen Build- und Freigabeprozess wie in anderen Optionen zu erstellen, indem automatisierte Tests verwendet werden (die im Arbeitsbereich selbst oder vor der Entwicklungsstufe erfolgen können), Genehmigungen usw.

Sobald die PR an die Hauptfiliale genehmigt und zusammengeführt wurde:

  1. Eine Buildpipeline wird ausgelöst, die die Änderungen mithilfe von Fabric Git-APIs in die Entwicklungsphase hochlädt. Bei Bedarf kann die Pipeline andere APIs auslösen, um Nachbereitstellungsvorgänge/Tests in der Entwicklungsphase zu starten.
  2. Nach Abschluss der Entwicklungsbereitstellung wird eine Releasepipeline gestartet, um die Änderungen von der Entwicklungsstufe bis zur Testphase bereitzustellen. Automatisierte und manuelle Tests sollten nach der Bereitstellung durchgeführt werden, um sicherzustellen, dass die Änderungen gut getestet werden, bevor sie die Produktion erreichen.
  3. Nach Abschluss der Tests genehmigt der Release-Manager die Bereitstellung in der Prod-Phase, woraufhin die Freigabe für Prod beginnt und die Bereitstellung abgeschlossen wird.

Wann sollten Sie die Option #3 verwenden?

  • Wenn Sie die Quellcodeverwaltung nur zu Entwicklungszwecken verwenden und Änderungen lieber direkt zwischen Phasen der Releasepipeline bereitstellen möchten.
  • Bei Bereitstellungsregeln sind die automatische Bindung und andere verfügbare APIs ausreichend, um die Konfigurationen zwischen den Phasen der Releasepipeline zu verwalten.
  • Wenn Sie andere Funktionen von Fabric-Bereitstellungspipelines verwenden möchten, z. B. Anzeigen von Änderungen in Fabric, Bereitstellungsverlauf usw.
  • Beachten Sie auch, dass Bereitstellungen in den Fabric-Bereitstellungspipelines eine lineare Struktur haben und dass zum Erstellen und Verwalten der Pipelines weitere Berechtigungen erforderlich sind.

Option 4 – CI/CD für ISVs in Fabric (Verwalten mehrerer Kunden/Lösungen)

Diagramm, das den Fluss der gitbasierten Bereitstellung für ISVs zeigt.

Diese Option unterscheidet sich von den anderen. Es ist am relevantesten für unabhängige Softwareanbieter (ISV), die SaaS-Anwendungen für ihre Kunden auf Fabric erstellen. ISVs verfügen in der Regel über einen separaten Arbeitsbereich für jeden Kunden und können bis zu mehrere hundert oder tausende Arbeitsbereiche haben. Wenn die Struktur der für jeden Kunden bereitgestellten Analysen ähnlich und sofort einsatzbereit ist, empfehlen wir, einen zentralisierten Entwicklungs- und Testprozess zu haben, der nur in der Prod-Phase auf jeden Kunden aufgeteilt wird.

Diese Option basiert auf option #2. Sobald die PR zum Hauptteil genehmigt und zusammengeführt wurde:

  1. Eine Buildpipeline wird ausgelöst, um eine neue Buildumgebung zu starten und Komponententests für die Entwicklungsstufe auszuführen. Wenn die Tests abgeschlossen sind, wird eine Veröffentlichungspipeline ausgelöst. Diese Pipeline kann den Inhalt in eine Buildumgebung hochladen, Skripts ausführen, um einige der Konfigurationen zu ändern, die Konfiguration an die Entwicklungsstufe anzupassen, und dann die Update-Elementdefinitions-APIs von Fabric verwenden, um die Dateien in den Arbeitsbereich hochzuladen.
  2. Nach Abschluss dieses Vorgangs, einschließlich der Datenaufnahme und der Genehmigung von Release-Managern, können die nächsten Build- und Release-Pipelines für die Testphase gestartet werden. Dieser Prozess ähnelt dem im ersten Schritt beschriebenen Verfahren. Für die Testphase sind möglicherweise andere automatisierte oder manuelle Tests nach der Bereitstellung erforderlich, um zu überprüfen, ob die Änderungen in der Prod-Stufe in hoher Qualität freigegeben werden können.
  3. Sobald alle Tests bestanden und der Genehmigungsprozess abgeschlossen ist, kann die Bereitstellung für Prod-Kunden beginnen. Jeder Kunde verfügt über eine eigene Version mit eigenen Parametern, sodass seine spezifische Konfiguration und Datenverbindung im Arbeitsbereich des relevanten Kunden erfolgen kann. Die Konfigurationsänderung kann durch Skripts in einer Buildumgebung oder mithilfe von APIs nach der Bereitstellung erfolgen. Alle Versionen können parallel erfolgen, da sie nicht miteinander verbunden oder voneinander abhängig sind.

Wann sollten Sie die Option #4 verwenden?

  • Sie sind ein ISV, der Anwendungen über Fabric erstellt.
  • Sie verwenden für jeden Kunden unterschiedliche Arbeitsbereiche, um die Mandantenfähigkeit Ihrer Anwendung zu verwalten.
  • Für eine größere Trennung oder für bestimmte Tests für unterschiedliche Kunden könnten Sie in früheren Entwicklungs oder Testphasen Multi-Tenancy haben. Beachten Sie in diesem Fall, dass durch die Nutzung von Mehrmandantenfähigkeit die Anzahl der benötigten Arbeitsbereiche erheblich wächst.

Zusammenfassung

In diesem Artikel werden die wichtigsten CI/CD-Optionen für ein Team zusammengefasst, das einen automatisierten CI/CD-Prozess in Fabric erstellen möchte. Während wir vier Optionen skizzieren, könnten sich die realen Einschränkungen und die Lösungsarchitektur möglicherweise für Hybridoptionen oder völlig andere Optionen anbieten. Sie können diesen Artikel verwenden, um Sie durch verschiedene Optionen und deren Erstellung zu führen, aber Sie sind nicht gezwungen, nur eine der Optionen auszuwählen.

Einige Szenarien oder bestimmte Elemente können Einschränkungen aufweisen, die Sie daran hindern können, eines dieser Szenarien zu übernehmen.

Dasselbe gilt für Werkzeuge. Obwohl hier verschiedene Tools erwähnt werden, können Sie andere Tools auswählen, die dieselbe Funktionalität bieten können. Berücksichtigen Sie, dass Fabric eine bessere Integration in einige Tools hat. Die Auswahl anderer führt also zu weiteren Einschränkungen, die unterschiedliche Problemumgehungen erfordern.

Zugehöriger Inhalt

  • Last updated on