本文說明如何利用 Git 整合與部署管線管理 Fabric 資料代理，作為 Microsoft Fabric 應用程式生命週期管理（ALM）功能的一部分。 您將瞭解如何將工作區連線至 Git 存放庫。 你也會學會如何追蹤及設定資料代理的設定。 最後，你將學會如何在開發、測試和生產環境中推動更新。 Git 整合與部署管線可啟用資料代理程式變更的持續整合與持續部署（CI/CD），允許更新在 ALM 工作流程中自動進行測試和推進。 Fabric 資料代理的原始碼控制目前處於預覽階段。
你可以使用兩種互補的方式來支援 Fabric 資料代理的 ALM：
- Git 整合：將整個工作空間與 Git 儲存庫（可選為 Azure DevOps 或 GitHub 作為 Git 提供者）同步，以啟用版本控制、透過分支協作，以及針對個別項目（包括 Fabric 資料代理）進行歷史追蹤。
- 部署管線：使用內建管線，在代表開發、測試和生產階段的個別工作區之間提升內容。
這些功能共同提供 Fabric 資料代理的端對端 ALM 支援。
先決條件
- 付費的 F2 或更高級別的 Fabric 容量，或啟用 Microsoft Fabric 的 Power BI Premium（P1 或更高級別）容量。
- 根據 Fabric 資料代理租戶設定中說明的需求，啟用 AI 的跨地理處理與跨地理儲存功能。
- 至少有一個資料來源，包含資料：倉庫、湖屋、Power BI 語意模型、KQL 資料庫、鏡像資料庫或本體。 你必須有讀取權限存取資料來源。
Git 整合
Microsoft Fabric Git 整合將 Fabric 工作空間與 Git 倉庫同步，讓您能直接在 Fabric 平台上使用現有的開發流程、工具與最佳實務。 它支援 Azure DevOps 和 GitHub，並且在工作區層級提供。 當你從 Fabric 提交變更，包括資料代理設定的更新時，這些變更會以檔案形式儲存在連接的 Git 儲存庫中。 其主要功能包括：
- 工作區項目的完整備份和版本控制
- Git 中的資料夾結構會鏡像工作區結構
- 資料代理程式設定 （結構描述選取、AI 指令、資料來源指令、範例查詢） 會儲存在專用資料夾中的結構化檔案中
- 能夠檢視差異、檢閱歷史記錄，以及透過不同工作區項目 （包括資料代理程式） 的歷史記錄還原到先前的狀態
- 分支型協作（功能分支、主分支）
最新的 Git 整合增強功能
Fabric Git 整合現在支援選擇性分支，讓你能在工作區層級切換連接的分支，以配合功能分支的工作流程。 原始碼控制面板還內建了項目變更的差異體驗，讓你在提交或拉取更新前能精確檢視變更內容。 分支工作區在 Fabric UI 中會更清楚標示，方便辨識每個工作區連接的分支。
如需 Git 整合程式的詳細資訊，您可以參考下列資源。
設定原始檔控制的連線
你可以從 Workspace settings 頁面，將你的 Fabric workspace 連接到 Git 儲存庫。 這個連線讓你能直接從 Fabric 提交並同步變更。
詳見 Get started with Git integration Azure DevOps或GitHub 連接 Git 倉庫的詳細步驟。
連接 Git 儲存庫後，您的工作區項目，包括 Fabric 資料代理程式，會出現在來源控制面板中。 在左下角的狀態列中，可以看到已連線分支的名稱、上次同步的時間以及Git提交ID。
- 連結的 Git 儲存庫會顯示一個資料夾結構，代表你的工作區項目，包括 Fabric 資料代理程式及其設定檔。 每個資料代理程式都儲存在自己的資料夾中，可讓您檢閱變更、追蹤版本歷程記錄，以及使用 Git 工作流程，例如建立提取要求，將更新合併到主分支中。
當你在連接 Git 的工作區中修改 Fabric 資料代理時，變更會被偵測到，且資料代理在原始碼控制面板中的狀態會變成未提交變更。 這些修改可以包括：
- 變更結構描述選擇。
- 更新 AI 指令或資料來源指令。
- 編輯範例查詢。
- 發佈資料代理程式或更新其發佈說明。
任何變更 （無論是功能性變更還是描述性變更） 都會導致資料代理程式與連結的 Git 存放庫不同步。 具有變更的工作區項目將出現在 [原始檔控制] 窗格的 [變更] 索引標籤下。 您可以檢閱這些變更，將它們與已提交的版本進行比較，並將它們提交回 Git 儲存庫進行同步處理。
- 當更新直接在連結的 Git 儲存庫（Azure DevOps 或 GitHub）進行時，可能包含修改 AI 指令、變更範例查詢或編輯發佈描述等動作。 然後，您可以提交這些變更並將其推送至存放庫。 一旦更新被推送並可在儲存庫中取得，你的 Fabric 工作區會偵測到這些更新，並在來源控制面板中顯示「更新可用」通知。 更新的項目 （例如資料代理程式） 會顯示在 [更新] 索引標籤下，您可以在其中檢閱並接受它們。 接受這些更新會將存放庫變更套用至您的工作區專案，確保工作區反映 Git 中最新的認可版本。
Git 存放庫中的資料夾和檔案結構
接下來，你將回顧資料代理設定如何儲存在 Git 儲存庫中的結構。 了解此結構對於管理變更和遵循最佳實踐非常重要。 使用功能分支時，請在綁定於工作區的分支中做變更，在 來源控制 面板中檢視差異，並透過拉取請求合併以進行受控的推廣。 資料代理的檔案與設定結構在各分支間保持一致。
根結構
在根目錄中，資料代理程式內容儲存在 檔案 資料夾下。 在 檔案中，您會找到一個 config 資料夾，其中包含 data_agent.json、 publish_info.json、 草稿資料夾 和 已發佈資料夾。
在 config 資料夾內， publish_info.json 包含資料代理程式的發佈說明。 可以更新此檔案，以變更發佈資料代理程式時顯示的說明。
草稿資料夾包含對應於資料代理程式草稿版本的組態檔，而已發佈資料夾則包含已發佈資料代理程式版本的組態檔。 草稿資料夾包含：
資料來源資料夾 ，其中資料代理程式使用的每個資料來源都有一個資料夾。 每個資料夾名稱以一個前綴開頭，標示資料來源類型，接著是資料來源名稱。 例如：
-
湖屋或倉儲資料來源：資料夾名稱以 或
lakehouse-tables-開頭warehouse-tables-，後面接著湖屋或倉儲的名稱。 -
語意模型資料來源：資料夾名稱以 開
semantic-model-頭，後面接著語意模型的名稱。 -
KQL 資料庫資料來源：資料夾名稱以 開
kusto-頭，後面接著 KQL 資料庫的名稱。 -
本體論資料來源：資料夾名稱以 開頭
ontology-，接著是本體名稱。
其他支援的資料來源，如 Fabric 中的 SQL 資料庫、鏡像資料庫、圖形模型及 Azure AI 搜尋服務，皆遵循相同的命名模式。 欲了解完整支援的資料來源清單，請參閱在 Fabric 資料代理中新增與設定資料來源。
-
湖屋或倉儲資料來源：資料夾名稱以 或
-
stage_config.json 包含
aiInstructions，它指的是代理程式指令。
每個資料來源資料夾都包含 datasource.json 和 fewshots.json。 不過，如果資料來源是語意模型，則不支援範例查詢，因此其資料夾僅包含 datasource.json。
datasource.json 會定義該資料來源的組態，包括：
dataSourceInstructions，代表為該資料來源提供的指示。displayName，其中顯示資料來源的名稱。elements，指的是架構映射，並包含來自資料來源的表格和欄位的完整清單。- 每個表格都有一個
is_selected屬性。 如果 ，則true包含資料表，如果 ，則false表示未選取資料表，且資料代理程式不會使用該資料表。 - 欄位項目也會顯示
is_selected，但目前不支援欄位層級的選擇。 如果選取表格，則無論資料行is_selected值為何，都會包含其所有資料行。 如果沒有選擇資料表（is_selected：在false資料表層級），則不會考慮任何資料行，即使is_selected在資料行層級被設為true。
- 每個表格都有一個
類型慣例：
- 如果類型是資料來源，則它只是資料來源類型 （例如：
"type": "lakehouse_tables"）。 - 如果類型是表格，則結尾為
.table（例如："type": "lakehouse_tables.table"）。 - 如果類型是資料行，則結尾為
.column（例如："type": "lakehouse_tables.column"）。
- 如果類型是資料來源，則它只是資料來源類型 （例如：
fewshots.json 會儲存資料來源的範例查詢。 每個條目包括：
-
id作為範例查詢的唯一識別碼。 -
question，指的是自然語言問題。 -
query顯示查詢文字，視資料來源類型而定，可能是 SQL 或 KQL。
已發佈的資料夾會鏡像草稿資料夾的結構，但代表資料代理程式的已發佈版本。 最佳做法是不要直接修改已發佈資料夾中的檔案。 應在草稿資料夾中進行變更。 發佈資料代理程式後，這些變更會反映在已發佈的資料夾中。 這可確保已發佈的版本一律從受控草稿狀態產生。
資料代理程式的部署管線
部署管道提供受控的方法，允許在配置至不同生命週期階段的工作區域之間移動資料代理程序。 例如：
- 開發新的資料代理程式，或更新開發工作區中的現有資料代理程式。
- 將變更推送至測試工作區以進行驗證。
- 將測試的變更升級至生產工作區，讓一般使用者可以使用。
在部署之前，您必須將工作區指派給部署管線中的每個階段：開發、測試和生產。 如果你沒有分配工作區到測試或運行階段，工作區會自動建立。 自動建立的工作區會以開發工作區命名，並附加 [test] 或 [prod]。
若要部署變更：
- 在管道中，移動至您要做部署的階段（例如：開發階段）。
- 選取工作區中您要部署的專案。
- 選取 [部署] 以將其升級至下一個階段。
您可以在套用變更之前檢閱部署計畫，確保只執行有計畫的更新。 如需詳細資訊，請參閱開始使用部署管線。
自動化 CI/CD 機制，運用 Azure DevOps Pipelines
Azure DevOps Pipelines 擴充功能
透過批次 API 進行批量同步（預覽）
匯入/匯出項目定義批次 API（預覽版）提供大規模項目定義同步的選項，包括資料代理設定。 你可以批量匯出和匯入資料代理定義，以簡化跨環境推廣。 欲了解更多資訊，請參閱 Fabric REST API 文件。
備註
服務主體僅在 Fabric Data agent 中作為 ALM 情境的一部分被支援。 此支援僅限於啟用 ALM 操作（如 Git 整合與部署管線），並未延伸至其他 Fabric 資料代理功能。 如果您需要在 ALM 工作流程之外與資料代理互動，則不支援 Service Principal。
發布一個 Fabric 資料代理程式以支援部署管線
發布 Fabric 資料代理程式後，能在所有不同消費管道中使用，包括 Copilot for Power BI、Microsoft Copilot Studio 及 Foundry Tools。 若要跨這些通道評估及取用資料代理程式，必須發佈資料代理程式;未發佈的資料代理程式即使位於生產工作區中，也無法存取以供使用。 若要遵循部署流程的最佳實務，請注意：
- 從開發工作區發佈應僅限於正在進行資料代理程式開發並想要評估其跨不同取用管道的效能的授權使用者。 必須限制對此工作區的存取，以免未完成或實驗性資料代理程式暴露給更廣泛的受眾。
- 使用者應該只存取從生產工作區發佈的資料代理程式，確保他們與穩定、核准的資料代理程式版本互動。
此方法支援啟用耗用量和效能評估的功能需求，並藉由將開發和生產環境分開來確保適當的存取控制。
最佳做法
- 使用專用分支進行數據代理的開發工作，並在程式碼檢閱後合併至主分支。
- 將相關資源 （資料來源、資料代理程式、筆記本、管線） 保留在同一個工作區中，以便於升級。
- 在升級至生產環境之前，先在測試工作區中測試資料代理程式變更。
- 使用描述性的提交信息，讓歷史更容易理解。
- 請勿直接變更 Git 存放庫中已發佈的資料夾。
- 使用環境無關的配置模式（例如支援時，透過變數函式庫的連線參考）以避免在資料代理資料來源設定中硬編碼環境特定值。 此做法促進了在開發、測試與生產環境中更順暢的分支合併與部署。
限制與考量
- 只有連線至 Git 儲存庫的工作區才能使用 Git 型 ALM 功能。
- 服務主體僅在 Fabric 資料代理中作為 ALM 情境的一部分被支援。 如果您需要在 ALM 工作流程之外與資料代理互動，則不支援 Service Principal。
- 部署管線要求來源和目標工作區位於同一租戶中。
- 大量頻繁的提交會影響儲存庫大小和效能。