Eksempler på distribusjonsplaner (forhåndsvisning)

Denne artikkelen viser mønstre som utplasseringsplaner ofte brukes til. Hver av dem beskriver distribusjonsgruppene og handlingene knyttet til dem, slik at du kan bygge tilsvarende på lerretet.

For hvordan du bygger en plan, se Lag en utplasseringsplan.

Distribuer et element som er avhengig av data et annet element produserer

Dette er den vanligste grunnen til å bruke en plan.

Arbeidsområdet

Et salgsteam oppbevarer analyseløsningen sin i et enkelt git-tilkoblet arbeidsområde som inneholder fire elementer:

Hvorfor ikke bare utplasseringsrekkefølge er nok

Fabric bruker item lineage for å oppdage at lagervisningen refererer til en lakehouse-tabell, så den deployerer lakehouse før lageret.

Lineage viser ikke at tabellen må fylles før visningen er gyldig. Tabellen kommer ikke med gjenstandsdefinisjonen. De to notatbøkene produserer den under kjøring:

Distribuerer du dette arbeidsområdet uten en plan, mislykkes utrullingen. Hvert element kopieres korrekt, men varelagervisningen opprettes mot en tabell som ingen har laget ennå, og distribusjonen rapporterer at objektnavnet er ugyldig. Målet blir delvis utplassert.

Det er ingenting galt med gjenstandene. Det som mangler er instruksjonen om å kjøre notatbøkene mellom utrulling av innsjøhuset og utrulling av lageret. Den instruksjonen er planen.

Planen

Planen har to utplasseringsgrupper, én for innsjøhuset og én for lageret. Lakehouse-gruppen kjører begge notatbøkene som post-deployeringsaksjoner:

Etter at innsjøhuset er utplassert, Hydrate_TopCustomers skriver kilderadene. Deretter Publish_TopCustomers oppretter dbo.top_customers og venter til SQL-analyseendepunktet eksponerer tabellen. Lakehouse-gruppen fullfører først etter at begge handlingene er ferdige. Fabric kan deretter distribuere lageret og lage sin visning.

Notatbøkene er handlinger i lakehouse-gruppen, ikke separate deployeringsgrupper. Publish_TopCustomers Det avhenger av Hydrate_TopCustomers, og lagergruppen avhenger av den ferdige Lakehouse-gruppen.

Her er samme plan på lerretet:

Forstå den plan.yml strukturen

Du bygger en plan på lerretet. Når arbeidsområdet er koblet til Git, lagres planen som en plan.yml fil i mappen til deployeringsplan-elementet, slik at den blir gjennomgått og versjonsbasert som alle andre elementer:

$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:

Noen ting å merke seg i denne definisjonen:

• En gruppe navngir én gjenstand. logicalId er elementets logiske ID, samme identifikator som Git-integrasjonen bruker, slik at planen forblir gyldig når elementet flyttes mellom arbeidsområder.
• Gruppeordenen uttrykkes med dependsOn, ikke etter posisjon i filen. Omorganisering av gruppene i filen endrer ingenting.
• Handlingsrekkefølgen uttrykkes også med dependsOn. Run Publish_TopCustomers starter først etter Run Hydrate_TopCustomers mål.
• postActions Løp etter at gruppens gjenstand er utplassert. Bruk preActions det til arbeid som må gjøres først, som en valideringssjekk.

Oppdater innholdet etter at det er distribuert

En utrulling oppdaterer varedefinisjoner. Den kjører ingenting, så en semantisk modell eller en rapport reflekterer den nye definisjonen, men ikke nye data.

Legg denne planen til en distribusjonspipeline-utrulling slik at promotering til et stadium etterlater målet klart til bruk i stedet for manuell oppdatering.

Valider før noe deployeres

En pre-deploy-handling kjøres før gjenstanden i gruppen deployeres, så du kan bruke en som port.

En handling kan bare kjøre et element som allerede er distribuert, så selve sjekken blir distribuert av en tidligere gruppe:

Hvis sjekken feiler, stopper utrullingen og ingenting som avhenger av den gruppen deployeres. Bruk dette for å bekrefte at tilkoblinger løses, at en nødvendig kapasitet kjører, eller at et kildesystem er tilgjengelig før en utgivelse begynner.

Bestillingsarbeid som slekten ikke kan se

To gjenstander kan være helt uavhengige når det gjelder slektslinje, og likevel kreve en bestilling. En plan er måten du uttrykker det på.

Fordi avhengigheten går gjennom en forbindelse i stedet for en gjenstandsreferanse, kan ikke Fabric utlede den. Planen leverer bestillingen.

Relatert innhold

• Hva er en utplasseringsplan?
• Lag en utrullingsplan
• Handlinger i utrullingsplanen
• Feilsøkingsplaner for utplassering