Freigeben über

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

  • Artikel

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 freigegebenen 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 ähnelt.

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 Verzweigungsstrategie folgt, einschließlich mehrerer Primärzweige.
  • Der Upload aus dem Repository wechselt direkt in den Arbeitsbereich, da wir keine Buildumgebungen benötigen, um die Dateien vor bereitstellungen zu ändern. 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 Releasepipeline ausgelöst, um den Inhalt in eine Buildumgebung hochzuladen, Skripts auszuführen, um einige der Konfigurationen zu ändern, die Konfiguration an die Entwicklungsstufe anzupassen und die Updateelementdefinitions-APIs von Fabric zum Hochladen der Dateien in den Arbeitsbereich zu verwenden.
  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 Releasepipelines 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 Releasepipelinen in die Prod-Phase genehmigen und starten. Da die Prod-Stufe in der Regel unterschiedliche Konfigurationen als Test-/Entwicklungsphasen aufweist, ist es wichtig, auch die Änderungen nach der Bereitstellung zu testen. Außerdem sollte die Bereitstellung eine weitere Erfassung von Daten basierend auf der Änderung auslösen, um potenzielle Nichtverfügbarkeit für Verbraucher zu minimieren.

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 trunkbasierten 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 , und die Freigabe für Prod beginnt und schließt die Bereitstellung ab.

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 Fabric-Bereitstellungspipelines eine lineare Struktur aufweisen und andere Berechtigungen zum Erstellen und Verwalten der Pipeline benötigen.

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 Tests abgeschlossen sind, wird eine Releasepipeline 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 Erfassung von Daten und der Genehmigung von Release-Managern, können die nächsten Build- und Releasepipelines 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 den Mandanten ihrer Anwendung mit mehreren Mandanten zu verwalten.
  • Für eine größere Trennung oder für bestimmte Tests für unterschiedliche Kunden sollten Sie in früheren Entwicklungs- oder Testphasen mehrere Mandanten haben. Beachten Sie in diesem Fall, dass die Anzahl der benötigten Arbeitsbereiche mit mehreren Mandanten 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önnen sich die Realen Einschränkungen und Lösungsarchitekturen für Hybridoptionen oder völlig andere optionen eignen. 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.

Das gleiche gilt für die Werkzeugerstellung. 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