Eksempler på udrulningsplaner (forhåndsvisning)

Denne artikel viser mønstre, som implementeringsplaner ofte bruges til. Hver beskriver deploy-grupperne og de handlinger, der er knyttet til dem, så du kan bygge den tilsvarende på lærredet.

For hvordan man bygger en plan, se Opret en udrulningsplan.

Udrul et element, der afhænger af data, et andet element producerer

Dette er den mest almindelige grund til at bruge en plan.

Arbejdsområdet

Et salgsteam opbevarer sin analyseløsning i et enkelt git-forbundet arbejdsområde, der rummer fire elementer:

Element Type Hvad den gør
Sales_Lakehouse Lakehouse Opbevarer salgsbordene. Den er tom, når den deployes, fordi en deployment kopierer item-definitioner, ikke data.
Hydrate_TopCustomers Notebook Skriver de rå kilde-rækker ind i søhuset.
Publish_TopCustomers Notebook Omdanner disse rækker til den offentliggjorte dbo.top_customers tabel.
Sales_Warehouse Lagersted Holder visningen dbo.vw_top_customers, som lyder dbo.top_customers.

Hvorfor udsendelsesrækkefølgen alene ikke er nok

Fabric bruger item lineage til at opdage, at lagervisningen refererer til en lakehouse-tabel, så den deployerer lakehouse før lageret.

Lineage viser ikke, at tabellen skal udfyldes , før visningen er gyldig. Tabellen kommer ikke med en genstandsdefinition. De to notebooks producerer den under kørsel:

Diagram viser Hydrate-notesbogen skrive en kildetabel ind i søhuset, Publish-notesbogen omdanne den til dbo.top_customers, og lagervisningen læse den tabel.

Udrul dette arbejdsområde uden en plan, og udrulningen fejler. Alle genstande kopieres korrekt, men lagervisningen oprettes mod en tabel, som ingen endnu har lavet, og udrulningen rapporterer, at objektnavnet er ugyldigt. Målet efterlades delvist udsat i feltet.

Der er ikke noget galt med genstandene. Det, der mangler, er instruktionen til at køre notesbøgerne mellem udrulning af søhuset og opsætning af lageret. Den instruktion er planen.

Planen

Planen har to udrulningsgrupper, én til søhuset og én til lageret. Lakehouse-gruppen kører begge notesbøger som post-deploy handlinger:

Udrulningsgruppe Udsendt genstand Handlinger efter udrulning Det afhænger af
Sales_Lakehouse Sales_Lakehouse (søhus) 1. Løb Hydrate_TopCustomers
2. Løb Publish_TopCustomers		 Intet
Sales_Warehouse Sales_Warehouse (lager) Ingen Sales_Lakehouse

Efter at lakehouse er deployed, Hydrate_TopCustomers skriver kilde-rækkerne. Derefter Publish_TopCustomers opretter dbo.top_customers og venter, indtil SQL-analyse-endpointet eksponerer tabellen. Lakehouse-gruppen slutter først, når begge handlinger er afsluttet. Fabric kan derefter deploye lageret og skabe dets visning.

Notesbøgerne er handlinger i lakehouse-gruppen, ikke separate deployeringsgrupper. Publish_TopCustomers Det afhænger af Hydrate_TopCustomers, og lagergruppen afhænger af den færdige Lakehouse-gruppe.

Her er den samme plan på lærredet:

Skærmbillede af SalesRelease-udrulningsplanen, der viser Sales_Lakehouse-gruppen med Hydrate_TopCustomers og Publish_TopCustomers som ordnede post-udrulningshandlinger, efterfulgt af den afhængige Sales_Warehouse-gruppe.

Forstå den plan.yml struktur

Du bygger en plan på lærredet. Når arbejdsområdet er forbundet til Git, gemmes planen som en plan.yml fil i mappen for deploy-plan-elementet, så den gennemgås og versionsbehandles som ethvert andet element:

$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

Filen har følgende struktur:

Element Formål
$schema Identificerer skemaet, der validerer planens definition.
version Identificerer planens definitionsversion.
groups Indeholder deploygrupperne i planen.
name Giver en gruppe eller handling et unikt navn, som afhængigheder kan referere til.
logicalId Identificerer Fabric-elementet på tværs af arbejdsområder.
dependsOn Deklarerer afhængigheder af en anden gruppe eller handling ved navn.
preActions Og postActions Kør understøttede jobs før eller efter gruppens item deployeres.
job Identificerer jobtypen, element-logisk ID og valgfrie parametre for en handling.

Et par ting at bemærke i denne definition:

  • En gruppe navngiver én genstand. logicalId er elementets logiske ID, den samme identifikator som Git-integration bruger, så planen forbliver gyldig, når elementet flyttes mellem arbejdsområder.
  • Gruppeordenen udtrykkes med dependsOn, ikke efter position i filen. At omarrangere grupperne i filen ændrer ingenting.
  • Handlingsrækkefølge udtrykkes også med dependsOn. Run Publish_TopCustomers starter først efter Run Hydrate_TopCustomers afslutningen.
  • postActions Løb efter gruppens genstand er udsendt. Brug preActions den til arbejde, der skal ske først, såsom en valideringskontrol.

Tips

En handling er færdig, når varens kørsel slutter, ikke når downstream-tjenester følger med. I dette eksempel venter den sidste celle af Publish_TopCustomers indtil lakehouse SQL-analyse-endpointet har katalogiseret den nye tabel. Sæt den slags beredskabstjek ind i handlingen, for planen venter ikke på dine vegne.

Opdater indhold efter udrulning

En udrulning opdaterer varedefinitioner. Den kører ikke noget, så en semantisk model eller en rapport afspejler den nye definition, men ikke nye data.

Udrulningsgruppe Udsendt genstand Kører efter at genstanden er udsendt Det afhænger af
Sales_Warehouse Sales_Warehouse (lager) Ingen Intet
Sales_Model Sales_Model (semantisk model) Kør en datapipeline, der opdaterer modellen Sales_Warehouse

Vedhæft denne plan til en deployment pipeline, så promovering til et trin efterlader målet klar til brug i stedet for at kræve en manuel opdatering.

Valider før noget implementeres

En pre-deploy-handling kører før genstanden i gruppen deployeres, så du kan bruge en som port.

En handling kan kun køre et objekt, der allerede er deployed, så selve checket bliver implementeret af en tidligere gruppe:

Udrulningsgruppe Udsendt genstand Kører før genstanden deployeres Det afhænger af
Forflyvning Preflight_Checks (notesbog) Ingen Intet
First_Real_Item Det første punkt i udgivelsen Løb Preflight_Checks Forflyvning

Hvis tjekket fejler, stopper udrulningen, og intet af det, der afhænger af den gruppe, deployeres. Brug dette til at bekræfte, at forbindelserne løses, at en krævet kapacitet kører, eller at et kildesystem er tilgængeligt, før en udgivelse begynder.

Bemærkning

En pre-deploy-handling kan ikke køre det item, dens egen gruppe deployer, fordi det item endnu ikke eksisterer i målet. Udrul det element, der udfører tjekket, i en tidligere gruppe, som vist her.

Ordensarbejde, som slægten ikke kan se

To genstande kan være helt uafhængige med hensyn til slægtslinje og stadig kræve en ordre. En plan er, hvordan du udtrykker det.

Udrulningsgruppe Udsendt genstand Det afhænger af
Reference_Data Elementet, der producerer referencedata Intet
Domain_Item Et element, der læser referencedata gennem en forbindelse i stedet for en direkte reference Reference_Data

Fordi afhængigheden løber gennem en forbindelse i stedet for en item-reference, kan Fabric ikke udlede den. Planen leverer ordren.

Relateret indhold

  • Last updated on