Exempel på distributionsplaner (förhandsvisning)

Den här artikeln visar mönster som utplaceringsplaner ofta används för. Varje beskrivning beskriver distributionsgrupperna och de åtgärder som är kopplade till dem, så att du kan bygga motsvarande på canvasen.

För hur man bygger en plan, se Skapa en distributionsplan.

Distribuera ett objekt som är beroende av data som ett annat objekt producerar

Detta är den vanligaste anledningen att använda en plan.

Arbetsytan

Ett säljteam har sin analyslösning i en enda Git-ansluten arbetsyta som rymmer fyra objekt:

Varför enbart distributionsordning inte räcker

Fabric använder objektursprung för att upptäcka att lagerdatabasvyn refererar till en lakehouse-tabell, så den distribuerar lakehouse innan lagerdatabasen.

Lineage visar inte att tabellen måste populeras innan vyn är giltig. Tabellen kommer inte med föremålsdefinitionen. De två anteckningsböckerna skapar den under körning:

Distribuera denna arbetsplats utan en plan och distributionen misslyckas. Varje objekt kopieras korrekt, men lagervyn skapas mot en tabell som ingen har producerat än, och distributionen rapporterar att objektnamnet är ogiltigt. Målet lämnas delvis utplacerat.

Det är inget fel på föremålen. Det som saknas är en instruktion om att köra notebookarna mellan distributionen av Lakehouse och distributionen av datalagret. Instruktionen är planen.

Planen

Planen har två utplaceringsgrupper, en för sjöhuset och en för lagret. Lakehousegruppen kör båda anteckningsböckerna som åtgärder efter distribution:

När lakehouse har distribuerats skriver Hydrate_TopCustomers källraderna. Sedan Publish_TopCustomers skapar dbo.top_customers och väntar tills SQL-analysändpunkten exponerar tabellen. Sjöhusgruppen avslutas först efter att båda handlingarna är klara. Fabric kan då distribuera lagret och skapa sin vy.

Anteckningsböckerna är handlingar i lakehouse-gruppen, inte separata distributionsgrupper. Publish_TopCustomers Det beror på Hydrate_TopCustomers, och lagergruppen beror på den färdiga Lakehouse-gruppen.

Här är samma plan på duken:

Förstå strukturen för plan.yml

Du bygger en plan på duken. När arbetsytan är ansluten till Git lagras planen som en plan.yml fil i mappen för utrullningsplanen, så den granskas och versionshanteras som vilket annat element som helst:

$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öljande struktur:

Några saker att notera i denna definition:

• En grupp namnger en sak. logicalId är objektets logiska ID, samma identifierare som Git-integrationen använder, så planen förblir giltig när objektet flyttas mellan arbetsytor.
• Gruppordningen uttrycks med dependsOn, inte med position i filen. Att omordna grupperna i filen förändrar ingenting.
• Handlingsordning uttrycks också med dependsOn. Run Publish_TopCustomers startar först efter att Run Hydrate_TopCustomers har slutförts.
• postActions körs efter att gruppens objekt har distribuerats. Använd preActions för arbete som måste göras först, som en valideringskontroll.

Uppdatera innehållet efter att det har distribuerats

En distribution uppdaterar objektdefinitioner. Den kör ingenting, så en semantisk modell eller en rapport speglar den nya definitionen men inte ny data.

Koppla denna plan till en distributionspipeline-utplacering så att en befordring till ett steg lämnar målet redo att användas istället för att behöva en manuell uppdatering.

Validera innan något distribueras

En åtgärd före distribution körs innan objektet i gruppen distribueras, så du kan använda den som en kontroll.

En åtgärd kan endast köra ett objekt som redan är distribuerat, så själva kontrollen distribueras av en tidigare grupp:

Om kontrollen misslyckas stoppas distributionen och inget som är beroende av den gruppen distribueras. Använd detta för att bekräfta att anslutningarna fungerar, att den nödvändiga kapaciteten är i drift eller att ett källsystem finns tillgängligt innan en lansering påbörjas.

Beställning av arbete som släktlinjen inte kan se

Två föremål kan vara helt oberoende när det gäller släktskap, och ändå behöva en ordning. En plan är hur du uttrycker det.

Eftersom beroendet går genom en koppling snarare än en artikelreferens kan Fabric inte dra slutsatsen. Planen tillhandahåller beställningen.

Relaterat innehåll

• Vad är en utplaceringsplan?
• Skapa en distributionsplan
• Åtgärder i utrullningsplanen
• Felsökningsplaner för utplacering