Voorbeelden van implementatieplannen (preview)

Dit artikel toont patronen waarvoor inzetplannen vaak worden gebruikt. Elk item beschrijft de deploymentgroepen en de daaraan gekoppelde acties, zodat je op het canvas het equivalent kunt opbouwen.

Voor hoe je een plan opstelt, zie Create a deployment plan.

Zet een item uit dat afhankelijk is van data die een ander item produceert

Dit is de meest voorkomende reden om een plan te gebruiken.

De werkruimte

Een salesteam houdt zijn analyse-oplossing in één git-verbonden werkruimte die vier items bevat:

Item	Typ	Wat het doet
`Sales_Lakehouse`	Lakehouse	Bewaart de verkooptabellen. Het is leeg wanneer het wordt uitgerold, omdat een implementatie de itemdefinities kopieert, niet de gegevens.
`Hydrate_TopCustomers`	Notitieboek	Schrijft de ruwe bronrijen in het meerhuis.
`Publish_TopCustomers`	Notitieboek	Maakt van die rijen de gepubliceerde `dbo.top_customers` tabel.
`Sales_Warehouse`	Magazijn	Houdt de weergave `dbo.vw_top_customers` vast, die luidt `dbo.top_customers`.

Waarom alleen de inzetvolgorde niet genoeg is

Fabric gebruikt item lineage om te bepalen dat de magazijnweergave naar een lakehouse-tabel verwijst, waardoor het lakehouse vóór het warehouse wordt geïmplementeerd.

Lineage laat niet zien dat de tabel gevuld moet zijn voordat de view geldig is. De tabel wordt niet meegeleverd bij de itemdefinitie. De twee notebooks genereren het tijdens de uitvoering:

Rol deze werkruimte uit zonder plan en mislukt de uitrol. Elk item wordt correct gekopieerd, maar de warehouse-weergave wordt aangemaakt tegen een tabel die nog niemand heeft gemaakt, en de deployment meldt dat de objectnaam ongeldig is. Het doelwit blijft gedeeltelijk uitgezet.

Er is niets mis met de items. Wat ontbreekt, is de instructie om de notebooks uit te voeren tussen het implementeren van het lakehouse en het implementeren van het datawarehouse. Die instructie is het plan.

Het plan

Het plan bestaat uit twee inzetgroepen, één voor het meerhuis en één voor het magazijn. De lakehouse-groep voert beide notitieboeken uit als post-deployment acties:

Implementatiegroep	Item geïmplementeerd	Acties na implementatie	Afhankelijk
Sales_Lakehouse	Sales_Lakehouse (meerhuis)	1. Voer Hydrate_TopCustomers uit 2. Voer Publish_TopCustomers uit	Niets
Sales_Warehouse	Sales_Warehouse (magazijn)	None	Sales_Lakehouse

Nadat het lakehouse is geïmplementeerd, schrijft Hydrate_TopCustomers de bronrijen. Vervolgens maakt Publish_TopCustomers de tabel dbo.top_customers aan en wacht het totdat het SQL-analyse-endpoint de tabel beschikbaar stelt. De lakehouse-groep eindigt pas nadat beide acties zijn afgerond. Fabric kan dan het warehouse deployen en zijn weergave creëren.

De notitieboeken zijn acties in de lakehouse-groep, niet aparte deployment-groepen. Publish_TopCustomers Het hangt af van Hydrate_TopCustomers, en de magazijngroep hangt af van de voltooide Lakehouse-groep.

Hier is hetzelfde plan op het canvas:

Begrijp de plan.yml structuur

Je bouwt een plan op het canvas. Wanneer de werkruimte verbonden is met Git, wordt het plan opgeslagen als een plan.yml bestand in de map van het deployment-plan item, zodat het wordt beoordeeld en versiegevat, net als elk ander item:

$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

Het bestand heeft de volgende structuur:

Element	Purpose
`$schema`	Identificeert het schema dat de plandefinitie valideert.
`version`	Identificeert de versie van de plandefinitie.
`groups`	Bevat de implementatiegroepen in het plan.
`name`	Geeft een groep of actie een unieke naam waarnaar afhankelijkheden kunnen verwijzen.
`logicalId`	Identificeert het Fabric-item in verschillende werkruimten.
`dependsOn`	Verklaart afhankelijkheden van een andere groep of actie bij naam.
`preActions` en `postActions`	Voer ondersteunde jobs uit vóór of nadat het item van de groep wordt uitgerold.
`job`	Identificeert het taaktype, het logische item-ID en optionele parameters voor een actie.

Een paar dingen om op te merken bij deze definitie:

Een groep noemt één voorwerp. logicalId is de logische ID van het item, dezelfde identifier die Git-integratie gebruikt, zodat het plan geldig blijft terwijl het item tussen werkruimtes beweegt.
Groepsvolgorde wordt uitgedrukt met dependsOn, niet per positie in het bestand. Het herschikken van de groepen in het bestand verandert niets.
Actievolgorde wordt ook uitgedrukt met dependsOn. Run Publish_TopCustomers begint pas nadat Run Hydrate_TopCustomers klaar is.
postActions Uitvoeren nadat het item van de groep is geïmplementeerd. Gebruik preActions het voor werk dat eerst moet gebeuren, zoals een validatiecontrole.

Tip

Een actie is voltooid wanneer de uitvoering van het item eindigt, niet wanneer onderliggende services weer bij zijn. In dit voorbeeld wacht de laatste cel tot Publish_TopCustomers het Lakehouse SQL-analyse-endpoint de nieuwe tabel heeft gecatalogiseerd. Plaats zo'n gereedheidscontrole binnen de actie, want het plan wacht niet op jou.

Ververs de inhoud nadat deze is uitgerold

Een implementatie werkt itemdefinities bij. Het draait niets, dus een semantisch model of een rapport weerspiegelt de nieuwe definitie maar geen nieuwe data.

Implementatiegroep	Item geïmplementeerd	Wordt uitgevoerd nadat het item is geïmplementeerd	Afhankelijk
Verkoopmagazijn	Sales_Warehouse (magazijn)	None	Niets
Sales_Model	Sales_Model (semantisch model)	Voer een datapijplijn uit die het model ververst	Sales_Warehouse

Koppel dit plan aan een deployment pipeline-implementatie zodat het promoten naar een fase het doelwit klaar maakt om te gebruiken in plaats van een handmatige verversing nodig te hebben.

Valideer voordat er iets wordt uitgezet

Een pre-deploy actie loopt voordat het item in zijn groep wordt gedeployt, dus je kunt er een als poort gebruiken.

Een actie kan alleen een item uitvoeren dat al is uitgerold, dus de check zelf wordt door een eerdere groep ingezet:

Implementatiegroep	Item geïmplementeerd	Draait voordat het item wordt ingezet	Afhankelijk
Voorafgaand aan de vlucht	Preflight_Checks (notitieboek)	None	Niets
First_Real_Item	Het eerste item van de release	Voer Preflight_Checks uit	Voorafgaand aan de vlucht

Als de controle mislukt, stopt de implementatie en wordt niets geïmplementeerd dat afhankelijk is van die groep. Gebruik dit om te bevestigen dat verbindingen worden opgelost, dat er een vereiste capaciteit draait, of dat er een bronsysteem beschikbaar is voordat een release begint.

Opmerking

Een pre-deploy actie kan het item dat zijn eigen groep deployt niet uitvoeren, omdat dat item nog niet in het doel bestaat. Zet het item dat de check uitvoert in een eerdere groep in, zoals hier getoond.

Bestel werk dat de lijn niet kan zien

Twee items kunnen volledig onafhankelijk zijn qua afstamming, en hebben toch een bestelling nodig. Een plan is hoe je dat uitdrukt.

Implementatiegroep	Item geïmplementeerd	Afhankelijk
Referentiegegevens	Het item dat referentiegegevens genereert	Niets
Domain_Item	Een item dat referentiegegevens leest via een verbinding in plaats van via een directe referentie	Referentiegegevens

Omdat de afhankelijkheid via een verbinding loopt in plaats van via een itemreferentie, kan Fabric het niet afleiden. Het plan bepaalt de volgorde.

Feedback

Is deze pagina nuttig?

Laatst bijgewerkt om 2026-09-29