當你在工作區間部署 Fabric 項目（例如從開發到測試再到生產環境）時，項目間的依賴關係可能會破裂。 有些項目會以 物件 ID（ 工作區專屬的 GUID）來儲存其相依關係的參考，而另一些則使用 邏輯 ID （檔案中儲存 .platform 的跨工作空間可攜式識別碼）。
在定義中使用邏輯 ID 的項目會正確綁定到目標工作區中對應的項目。 使用物件 ID 的項目仍指向來源工作區，這會破壞部署。
本文說明了使用 Git 整合時，哪些 Fabric 項目類型支援邏輯 ID 相依綁定，哪些不支援。 欲了解更多關於邏輯 ID 以及項目在原始碼控制中如何表示，請參閱 Fabric 中的邏輯 ID。
關鍵概念
-
邏輯識別碼：檔案中
.platform自動產生的跨工作空間識別碼。 具有相同邏輯 ID 的項目在工作區間被視為同一項目。 - 物件 ID：一個特定工作區的 GUID，用來識別特定實例。 物件 ID 無法在跨工作空間部署中存活，除非手動介入或參數化。
- 相依綁定（Git）：當你將 Git 分支同步到新工作區時，Fabric 會用邏輯 ID 解析相依性參考，並自動指向目標工作區中的正確項目。
- 依名稱或 URI：有些項目以顯示名稱或 URI 而非 ID 來參考相依關係。 這些參照可能會也可能不會正確解析，取決於各工作區之間的命名慣例。
依賴綁定的運作方式
在工作區中，項目會透過物件 ID 來參考其相依關係。 當 Fabric 將項目匯出到 Git 時，會將部分物件 ID 替換成檔案中的.platform邏輯 ID。 當你將 Git 分支同步到另一個工作區時，Fabric 會將那些邏輯 ID 解析回目標工作區的正確物件 ID。 這就是依賴綁定之所以有效的原因。
然而，並非所有依賴性參考在匯出時都會被邏輯 ID 取代。 在 Git 表示法中保留物件 ID 的項目，在同步後仍會指向原始工作區，而你需要手動更新這些項目，或透過參數化加以更新。
部署計畫與邏輯識別碼
當你儲存部署計畫時，Fabric 會為每個尚未有邏輯 ID 的參考項目指派一個邏輯 ID。 計畫會儲存該邏輯 ID，以便在計畫移動到其他工作區時辨識對應項目。
為被參考的項目指派邏輯 ID 並不會改變該項目自身相依關係的儲存方式。 以下表格中的相依綁定行為在使用方案進行部署時仍然適用。 在使用計畫到其他工作空間前，請先檢視計畫的行動步驟及其相依關係。
儲存需要對每個被參考的項目寫入權限，因為指派邏輯 ID 會更新項目。 如果 Fabric 無法為參考項目類型指派邏輯 ID，該計畫就無法儲存。
這很重要
相依綁定僅適用於同一工作區內 Fabric 項目之間的參考。 如果某個項目參照了 不同的工作區 中的 Fabric 項目，該參照會使用物件識別碼，且不會自動繫結。 對連線（資料來源連線、閘道）的參照也不會自動繫結。 使用帶有環境專屬值集的 變數函式庫 來管理跨環境的連線參考。
相依性繫結相容性
以下表格顯示在跨工作區部署時，每種 Fabric 項目類型的相依性是否正確綁定。 目前本文涵蓋 Git 整合 行為。 由於綁定是由每個項目如何在定義中儲存相依參考而決定，其他重複使用這些定義的部署機制（如部署管線與匯入（批量）API 也同樣適用。
這些資料表假設該相依性是來源項目所在 同一個工作區 中的另一個項目。 對 不同工作區 中某個項目的參照永遠不會自動繫結。 無論表格中顯示的值為何，它都會固定在來源物件 ID。
Git 中的自動繫結欄顯示：
- 是的：Git 中的項目定義會將相依性參考儲存為邏輯 ID。 當你將分支同步到新工作區時，參考會自動綁定到該工作區中匹配的項目。
- 不：Git 中的項目定義會將相依關係參考儲存為物件 ID（工作區專用 GUID）。 同步後，參考仍指向來源工作區。你需要手動更新或參數化它，才能跨工作空間部署。
- 部分：項目透過名稱或 URI 解決相依性，若命名在工作區間一致，這可能可行。
Notebooks
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| Lakehouse | Yes | 需要在筆記本設定中啟用「Git 中的 Lakehouse 自動繫結」。 啟用後，物件 ID 會被替換為 中的 notebook-settings.json邏輯 ID。 根據預設，此設定為關閉狀態。 欲了解更多資訊，請參閱 Git 中的 Lakehouse 自動綁定。 |
| Environment | Yes | |
| 鏡像資料庫 | No |
備註
Notebook 到 Lakehouse 綁定預設沒有啟用。 你需要在每個筆記本的設定內啟用「Git 中的 Lakehouse 自動繫結」設定。 欲了解更多資訊，請參閱 Notebook 的原始碼控制與部署。
Reports
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| 語意模型（來自 Power BI 報告） | 部分的 | 報告是透過byPath中的相對definition.pbir參照來參照模型，而不是透過明確的邏輯 ID。 當模型部署到目標工作空間中的相同相對位置時，能正確解析，但不會經由邏輯 ID 進行繫結。 更多資訊請參閱 Power BI Desktop 專案報告資料夾。 |
| 語意模型（來自分頁報告） | No | 報表的 連接字串 會透過一個工作區專用的 ID 參考語意模型，該 ID 在部署時不會重寫，因此它會指向來源模型。 你需要更新這個參考資料以進行跨工作空間部署。 （在 Report Builder 中撰寫且依名稱參照模型的報告，可能會改為依顯示名稱「Partial」解析。） |
管線
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| 管線 | Yes | |
| Notebook | Yes | |
| 數據流 Gen2 | Yes | |
| SQL 資料庫 | Yes | |
| Spark 工作定義 | No | SparkJobDefinition 活動是以物件 ID 而非邏輯 ID 參照 Spark Job Definition，因此部署後仍指向來源項目。 你需要將此值參數化，以利跨工作空間部署。 |
| Lakehouse | Yes | |
| 語意模型 | No | PBISemanticModelRefresh 活動以項目 ID 參照語意模型，而非邏輯 ID。 你需要將此值參數化，以利跨工作空間部署。 |
| 倉儲 | No | 倉庫 artifactId 透過邏輯 ID 解析並重新綁定，但 linkedService 同時也儲存來源工作區的 SQL 檔，這些 SQL endpoint不會被重寫。 為了跨工作區部署，將 endpoint 參數化。 |
語意模型
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| 語意模型 | 部分的 | 鏈式或複合模型參考會依名稱使用連接字串。 |
| SQL Analytics Endpoint（lakehouse） | No | TMDL expressions.tmdl 中的 Direct Lake 連接字串 包含工作區專屬的端點 URL 與資料庫 GUID。 你需要替換這些參數以進行跨工作空間部署。 |
| KQL 資料庫 | No | TMDL 表達式中包含叢集 URI 的連線字串含有工作區特定值。 |
| SQL 資料庫 | No | TMDL 表達式中的 連接字串 包含工作區特定的值。 |
| 倉儲 | No | 與倉庫 SQL 分析端點的連線使用工作區專用的 URL。 |
湖畔別墅
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| 湖屋（捷徑） | Yes | 指向另一個 Fabric 項目（例如湖屋或倉庫）的內部 OneLake 捷徑，會以邏輯 ID 的形式儲存，並重新繫結至目標工作區中的項目。 指向外部來源的捷徑（例如 Azure Data Lake Storage Gen2 或 Amazon S3）會指向 Fabric 外部，並改為帶有連線參考，因此不受邏輯 ID 繫結約束。 欲了解捷徑目標的完整清單，請參見 OneLake 捷徑。 關於部署行為，請參見 Lakehouse Git 整合與部署管線。 |
資料流（Gen2）
預設情況下，Dataflow Gen2 會建立對 Fabric 項目的絕對參考：查詢會儲存來源工作區 ID 與物件的物件 ID，部署時不會重寫。 來源參考也可以改用相對參考：當你在 Fabric 連接器中選取 !(Current Workspace) 節點下的項目時，查詢會以名稱儲存該項目（不使用 GUID），並在部署時解析為目標工作區中相符的項目。 輸出目的地一律使用絕對參照，且不會重新繫結。 對於目的地及任何絕對來源參照，請將其值參數化，以利跨工作空間部署。 欲了解更多資訊，請參閱 Dataflow Gen2 中 Fabric 連接器的相關參考，以及 Dataflow Gen2 與 CI/CD 與 Git 整合的相關參考。
資料來源：
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| Lakehouse | 部分的 | 只有在以相對參照撰寫時（!(Current Workspace)）才會重新繫結；預設的絕對參照不會重新繫結。 |
| 倉儲 | 部分的 | 只有在以相對參照撰寫時（!(Current Workspace)）才會重新繫結；預設的絕對參照不會重新繫結。 |
目的地參考：
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| Lakehouse | No | |
| 倉儲 | No | |
| SQL 資料庫 | No |
Spark 作業定義
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| Environment | Yes | |
| Lakehouse | No |
defaultLakehouseArtifactId 使用物件識別碼。 |
抄寫工作
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| Lakehouse | Yes | |
| 倉儲 | No | 倉庫 artifactId 透過邏輯 ID 解析並重新綁定，但 linkedService 同時也儲存來源工作區的 SQL 檔，這些 SQL endPoint不會被重寫。 為了跨工作區部署，將 endPoint 參數化。 |
| SQL 資料庫 | Yes |
GraphQL API
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| SQL 分析端點 | Yes | |
| 倉儲 | Yes | |
| SQL 資料庫 | Yes |
對於所有 GraphQL API 資料來源，部署後你可能需要重新設定連線和憑證。
事件流
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| Lakehouse | Yes | |
| Eventhouse | Yes | 當項目在同一工作區時，所有目的地都完全支援 CI/CD。 如果是 Eventhouse 的直接擷取模式，部署後可能需要手動重新設定連線。 欲了解更多資訊，請參閱 Eventstream CI/CD。 |
| 啟動器（Reflex） | Yes | 當項目在同一工作區時，所有目的地都完全支援 CI/CD。 欲了解更多資訊，請參閱 Eventstream CI/CD。 |
KQL 項目
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| KQL 資料庫到 Eventhouse | Yes |
parentEventhouseItemId 中的 DatabaseProperties.json 是邏輯識別碼，並會繫結至目標事件屋。 KQL 資料庫會作為其父 Eventhouse 的子項進行部署。 |
| KQL 查詢集至 KQL 資料庫 | 部分的 | 是透過 clusterUri 和 databaseName 進行解析，而不是透過項目識別碼。 定義中包含一個 databaseItemId，但它是一個不會重新綁定的物件 ID，因此解析取決於不同環境的 URI。 |
| 即時儀表板到 KQL 資料庫 | 部分的 | 使用 dataSources 帶有叢集 URI 的陣列。 跟 KQL queryset 的模式一樣。 |
倉儲
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| 倉庫 (交互參照) | No | 對其他倉庫的參照會使用物件 ID。 |
| SQL 分析端點 | No | SQL 分析端點參考使用工作區專屬識別碼。 |
變數函式庫
| 依賴性 | Git 中的自動綁定 | Notes |
|---|---|---|
| Fabric 項目 (ItemReference 類型) | No |
ItemReference 變數類型會將 workspaceId 和 itemId 儲存為原始 GUID。 你必須透過每個環境的值集手動更新或覆寫這些值。 |
無相依的項目
以下項目不存在跨工作空間依賴綁定問題：
- Environment
- SQL 資料庫
- Eventhouse（容器項目；KQL 資料庫會引用它）
- 鏡像資料庫（僅限外部來源設定）
總結
當你在工作區間部署 Fabric 項目時，如果參考以工作區專屬物件 ID 而非可攜式邏輯 ID 儲存，項目間的依賴關係可能會破裂。 並非所有項目類型都支援透過邏輯 ID 進行相依性繫結。 在建立跨工作空間部署前，請先檢視本文中的相容性表，辨識哪些相依關係會自動綁定，哪些則需要手動參數化。