Beispiele für Bereitstellungspläne (Vorschau)

Dieser Artikel zeigt Muster, für die Bereitstellungspläne häufig verwendet werden. Jede davon beschreibt die Bereitstellungsgruppen und die ihnen zugeordneten Aktionen, sodass du sie auf der Arbeitsfläche nachbilden kannst.

Wie man einen Plan erstellt, siehe Erstellen eines Einsatzplans.

Deploye ein Item, das von Daten abhängt, die ein anderes Item erzeugt

Dies ist der häufigste Grund, einen Tarif zu verwenden.

Der Arbeitsbereich

Ein Vertriebsteam bewahrt seine Analyselösung in einem einzigen, mit Git-verbundenen Arbeitsbereich auf, der vier Elemente umfasst:

Item	Typ	Was es bewirkt
`Sales_Lakehouse`	Lakehouse	Speichert die Verkaufstabellen. Es ist bei der Bereitstellung leer, da bei einer Bereitstellung Elementdefinitionen kopiert werden, nicht die Daten.
`Hydrate_TopCustomers`	Notebook	Schreibt die Rohdatenzeilen der Quelle in das Lakehouse.
`Publish_TopCustomers`	Notebook	Diese Zeilen werden in die veröffentlichte `dbo.top_customers` Tabelle umgewandelt.
`Sales_Warehouse`	Lagerhalle	Hält die Ansicht `dbo.vw_top_customers`, die lautet `dbo.top_customers`.

Warum allein die Einsatzreihenfolge nicht ausreicht

Fabric nutzt die Item-Lineage, um zu erkennen, dass die Lagerhausansicht auf eine Seehaus-Tabelle verwiesen ist, sodass es das Seehaus vor dem Lagerhaus einsetzt.

Lineage zeigt nicht, dass die Tabelle befüllt werden muss, bevor die Ansicht gültig ist. Die Tabelle wird nicht mit der Elementdefinition geliefert. Die beiden Notebooks erzeugen es zur Laufzeit:

Setzt man diesen Arbeitsbereich ohne Plan aus, schlägt die Bereitstellung fehl. Jeder Artikel wird korrekt kopiert, aber die Warehouse-Ansicht wird auf Basis einer Tabelle erstellt, die noch niemand angelegt hat, und die Bereitstellung meldet, dass der Objektname ungültig ist. Das Ziel wird teilweise ausgefahren belassen.

Mit den Gegenständen ist nichts falsch. Was fehlt, ist die Anweisung, die Notebooks zwischen der Bereitstellung des Lakehouse und der Bereitstellung des Warehouse auszuführen. Diese Anweisung ist der Plan.

Der Plan

Der Plan umfasst zwei Einsatzgruppen, eine für das Seehaus und eine für das Lagerhaus. Die Lakehouse-Gruppe betreibt beide Notizbücher als Post-Deployment-Aktionen:

Bereitstellungsgruppe	Eingesetzter Gegenstand	Aktionen nach dem Einsatz	Hängt
Sales_Lakehouse	Sales_Lakehouse (Seehaus)	1. Führen Sie Hydrate_TopCustomers aus 2. Führen Sie Publish_TopCustomers aus.	Nichts
Sales_Warehouse	Sales_Warehouse (Lagerhaus)	None	Sales_Lakehouse

Nachdem das Lakehouse bereitgestellt wurde, schreibt Hydrate_TopCustomers die Quellzeilen. Dann Publish_TopCustomers erstellt dbo.top_customers und wartet, bis der SQL-Analytics-Endpunkt die Tabelle offenstellt. Die Seehaus-Gruppe beendet erst, nachdem beide Aktionen abgeschlossen sind. Fabric kann dann das Warehouse bereitstellen und dessen Ansicht erstellen.

Die Notizbücher sind Aktionen in der Lakehouse-Gruppe, nicht in separaten Einsatzgruppen. Publish_TopCustomers hängt von Hydrate_TopCustomers ab, und die Warehouse-Gruppe hängt von der abgeschlossenen Lakehouse-Gruppe ab.

Hier ist derselbe Plan auf der Leinwand:

Verstehen Sie die Struktur von plan.yml

Man baut einen Plan auf der Leinwand. Wenn der Arbeitsbereich mit Git verbunden ist, wird der Plan als plan.yml Datei im Ordner des Deployment-Plan-Elements gespeichert, sodass er wie jedes andere Element überprüft und versioniert wird:

$schema: https://developer.microsoft.com/json-schemas/fabric/item/deploymentPlan/definition/plan/1.0.0/schema.json
version: 1.0.0
groups:
  - name: Sales_Lakehouse
    logicalId: 11111111-1111-1111-1111-111111111111
    postActions:
      - name: Run Hydrate_TopCustomers
        job:
          type: Execute
          logicalId: 22222222-2222-2222-2222-222222222222
      - name: Run Publish_TopCustomers
        dependsOn:
          - actionName: Run Hydrate_TopCustomers
        job:
          type: Execute
          logicalId: 33333333-3333-3333-3333-333333333333
  - name: Sales_Warehouse
    logicalId: 44444444-4444-4444-4444-444444444444
    dependsOn:
      - groupName: Sales_Lakehouse

Die Datei weist die folgende Struktur auf:

Element	Purpose
`$schema`	Identifiziert das Schema, das die Plandefinition validiert.
`version`	Identifiziert die Version der Plandefinition.
`groups`	Enthält die Bereitstellungsgruppen im Plan.
`name`	Gibt einer Gruppe oder Aktion einen eindeutigen Namen, auf den Abhängigkeiten verweisen können.
`logicalId`	Identifiziert das Fabric-Element arbeitsbereichsübergreifend.
`dependsOn`	Deklariert Abhängigkeiten von einer anderen Gruppe oder Aktion mit Namen.
`preActions` und `postActions`	Führen Sie unterstützte Jobs aus, bevor oder nachdem das Element der Gruppe bereitgestellt wird.
`job`	Identifiziert den Jobtyp, die logische Item-ID und optionale Parameter für eine Aktion.

Ein paar Dinge, die man bei dieser Definition beachten sollte:

Eine Gruppe nennt einen Gegenstand. logicalId ist die logische ID des Elements, dieselbe Identifikator, die die Git-Integration verwendet, sodass der Plan gültig bleibt, während der Artikel zwischen Arbeitsbereichen wechselt.
Die Gruppenordnung wird mit dependsOnangegeben, nicht nach Position in der Datei. Die Reihenfolge der Gruppen in der Datei ändert nichts.
Die Aktionsreihenfolge wird ebenfalls mit dependsOnausgedrückt. Run Publish_TopCustomers startet erst, nachdem Run Hydrate_TopCustomers abgeschlossen ist.
postActions wird ausgeführt, nachdem das Element der Gruppe bereitgestellt wurde. Nutzen preActions Sie sie für Arbeiten, die zuerst erledigt werden müssen, wie zum Beispiel eine Validierungsprüfung.

Tipp

Eine Aktion ist abgeschlossen, wenn die Ausführung des Elements endet, nicht wenn nachgelagerte Dienste nachgezogen haben. In diesem Beispiel wartet die letzte Zelle Publish_TopCustomers , bis der Lakehouse SQL-Analytics-Endpunkt die neue Tabelle katalogisiert hat. Integrieren Sie diese Art von Bereitschaftsprüfung direkt in die Aktion, denn der Plan wartet nicht auf Sie.

Inhalte nach der Bereitstellung aktualisieren

Eine Bereitstellung aktualisiert die Elementdefinitionen. Es läuft nichts, daher spiegelt ein semantisches Modell oder ein Bericht die neue Definition wider, aber keine neuen Daten.

Bereitstellungsgruppe	Eingesetzter Gegenstand	Läuft, nachdem der Gegenstand eingesetzt wurde	Hängt
Sales_Warehouse	Sales_Warehouse (Lagerhaus)	None	Nichts
Sales_Model	Sales_Model (semantisches Modell)	Führen Sie eine Datenpipeline aus, die das Modell aktualisiert	Sales_Warehouse

Fügen Sie diesen Plan einer Deployment-Pipeline-Bereitstellung zu, sodass das Promodieren auf eine Stufe das Ziel einsatzbereit lässt, anstatt eine manuelle Aktualisierung zu benötigen.

Validieren Sie, bevor etwas ausgerollt wird

Eine Pre-Deploy-Aktion läuft, bevor der Gegenstand in seiner Gruppe eingesetzt wird, sodass du einen als Tor nutzen kannst.

Eine Aktion kann nur einen bereits eingesetzten Gegenstand ausführen, daher wird der Check selbst von einer früheren Gruppe eingesetzt:

Bereitstellungsgruppe	Eingesetzter Gegenstand	Läuft, bevor der Gegenstand eingesetzt wird	Hängt
Vorflug	Preflight_Checks (Notizbuch)	None	Nichts
First_Real_Item	Der erste Punkt des Releases	Führen Sie Preflight_Checks aus	Vorflug

Wenn die Prüfung fehlschlägt, wird die Bereitstellung gestoppt, und nichts, was von dieser Gruppe abhängt, wird bereitgestellt. Verwenden Sie dies, um zu bestätigen, dass Verbindungen aufgelöst werden, dass eine erforderliche Kapazität läuft oder dass ein Quellsystem verfügbar ist, bevor eine Freigabe beginnt.

Hinweis

Eine Pre-Deploy-Aktion kann das Item, das ihre eigene Gruppe deployiert, nicht ausführen, weil dieses Item im Ziel noch nicht existiert. Deployiere das Element, das die Prüfung durchführt, in einer früheren Gruppe, wie hier gezeigt.

Bestelle Werke, die die Linie nicht sehen kann

Zwei Gegenstände können in Bezug auf die Abstammung völlig unabhängig sein und benötigen trotzdem eine Reihenfolge. Ein Plan ist, wie du das ausdrückst.

Bereitstellungsgruppe	Eingesetzter Gegenstand	Hängt
Referenzdaten	Das Element, das Referenzdaten erzeugt	Nichts
Domain_Item	Ein Element, das Referenzdaten über eine Verbindung statt über eine direkte Referenz liest	Referenzdaten

Da die Abhängigkeit über eine Verbindung und nicht über eine Item-Referenz läuft, kann Fabric sie nicht ableiten. Der Plan liefert die Ordnung.

Feedback

War diese Seite hilfreich?

Zuletzt aktualisiert um 2026-09-29