部署計畫範例（預覽）

本文展示了部署計畫常用的模式。每一項都會說明部署群組及附加到這些群組的動作，讓你能在畫布上建立對應的內容。

關於如何建立計畫，請參見「建立部署計畫」。

部署依賴另一個項目所產生資料的項目

這是使用保險計畫最常見的理由。

工作區

銷售團隊將分析解決方案放在一個連接 git 的工作區中，該工作區包含四個項目：

Item	類型	其功能是什麼
`Sales_Lakehouse`	Lakehouse	儲存銷售資料表。部署時它是空的，因為部署是複製項目定義，不是資料。
`Hydrate_TopCustomers`	Notebook	將原始來源資料列寫入湖倉。
`Publish_TopCustomers`	Notebook	把那些列轉成已發佈 `dbo.top_customers` 的表格。
`Sales_Warehouse`	倉儲	保持視角 `dbo.vw_top_customers`，讀為 `dbo.top_customers`。

為什麼僅靠部署順序還不夠

Fabric 利用項目血統來偵測倉庫視圖是否參考湖屋表，因此它會先部署湖屋而非倉庫。

沿襲關係並未表明表格必須先填入資料，視圖才會有效。表格沒有附帶物品定義。這兩個筆記本檔會在執行階段產生它：

如果沒有計畫地部署這個工作空間，部署就會失敗。每個項目都已正確複製，但倉儲檢視是根據一個尚未建立的資料表所建立，因此部署時會回報該物件名稱無效。目標處於部分展開狀態。

這些物品本身沒有問題。缺少的是在部署湖屋和部署倉庫之間執行筆記本的指令。那個指示就是計畫。

方案

計畫有兩個部署小組，一個負責湖邊小屋，一個負責倉庫。湖倉群組會將這兩個筆記本作為部署後作業來執行：

部署組	已部署的物品	部署後行動	這要看情況
銷售_湖倉	Sales_Lakehouse（湖畔別墅）	1. 執行 Hydrate_TopCustomers 2. 執行 Publish_TopCustomers	無
Sales_Warehouse	Sales_Warehouse（倉庫）	None	銷售_湖倉

在 lakehouse 部署完成後，Hydrate_TopCustomers 會寫入來源資料列。接著 Publish_TopCustomers 建立 dbo.top_customers 並等待 SQL 分析端將資料表暴露出來。 Lakehouse 群組必須等到兩個動作都完成後才會結束。接著 Fabric 可以部署倉庫並建立其視圖。

筆記本是湖倉群組中的操作，不是獨立的部署群組。 Publish_TopCustomers 取決於 Hydrate_TopCustomers，而倉庫群組則取決於已完成的湖屋群組。

畫布上的同樣計畫如下：

了解 plan.yml 的結構

你在畫布上建立計畫。當工作區連接到 Git 時，計畫會以 plan.yml 檔案形式儲存在部署計畫項目的資料夾中，因此會像其他項目一樣被檢視和設定版本：

$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

該檔案的結構如下：

Element	Purpose
`$schema`	識別驗證計畫定義的架構。
`version`	識別計畫定義版本。
`groups`	包含計畫中的各個部署群組。
`name`	賦予群組或動作唯一名稱，供相依關係參考。
`logicalId`	用來跨多個工作區識別 Fabric 項目。
`dependsOn`	以名稱宣告對另一個群組或行動的依賴。
`preActions` 與 `postActions`	在群組物品部署前後執行支援工作。
`job`	識別工作類型、項目邏輯 ID 及動作的可選參數。

這個定義中有幾點需要注意：

一個群組為一個項目命名。 logicalId 是該項目的邏輯 ID，與 Git 整合使用的識別碼相同，因此計畫在項目在工作空間間移動時仍保持有效。
群序以表示，dependsOn而非檔案中的位置。重新排序檔案中的群組不會改變任何東西。
動作順序也可用表示。dependsOn Run Publish_TopCustomers 只有在 Run Hydrate_TopCustomers 完成後才會開始。
postActions 在群組的項目部署後執行。 使用 preActions 處理必須先執行的工作，例如驗證。

小提示

當該項目的執行結束時，該操作即視為完成，而不是等到下游服務完成同步時。在這個例子中，Publish_TopCustomers 的最後一個儲存格會等到 Lakehouse SQL 分析端點已將新資料表編入目錄。把這種就緒檢查納入操作中，因為計畫不會等你準備好。

部署後重新整理內容

部署會更新項目定義。它不會執行任何東西，所以語意模型或報告會反映新的定義，但不會反映新的資料。

部署組	已部署的物品	在項目部署後執行	這要看情況
Sales_Warehouse	Sales_Warehouse（倉庫）	None	無
銷售_模型	Sales_Model（語意模型）	執行一個資料管線來刷新模型	Sales_Warehouse

將此計畫附加到部署管線中的部署作業，讓目標在提升至某個階段後即可立即使用，而不需要手動重新整理。

部署前先驗證

部署前動作會在其群組中的項目部署之前執行，因此你可以將它用作把關機制。

一個動作只能執行已經部署的項目，因此檢查本身是由較早的群組部署：

部署組	已部署的物品	在物品部署前執行	這要看情況
出前檢查	Preflight_Checks (筆記本)	None	無
First_Real_Item	此次發布的第一項	執行 Preflight_Checks	出前檢查

如果檢查失敗，部署就會停止，而且任何依賴該群組的項目都不會進行部署。利用此方法確認連線已解決、所需容量是否正在運行，或在釋出開始前有原始碼系統可用。

備註

部署前的動作無法執行它自己群組部署的物品，因為該物品還不存在於目標中。將執行檢查的項目部署在較早的群組中，如圖所示。

排序資料沿襲看不到的工作

兩個項目就沿襲關係而言可以完全互相獨立，但仍然需要有順序。計畫就是你表達這一切的方式。

部署組	已部署的物品	這要看情況
參考資料	產生參考資料的項目	無
Domain_Item	一個透過連線而非直接引用讀取參考資料的項目	參考資料

因為依賴是透過連線而非項目參考，Fabric 無法推斷出它。計畫提供秩序。

意見反應

此頁面對您有幫助嗎？

上次更新時間： 2026-09-29