本文介绍如何使用 Git 集成和部署管道来管理 Fabric 数据代理，作为 Microsoft Fabric 的应用程序生命周期管理 （ALM） 功能的一部分。 了解如何将工作区连接到 Git 存储库。 你还将了解如何跟踪和版本化数据代理配置。 最后，你将了解如何跨开发、测试和生产环境推广更新。 Git 集成和部署管道支持数据代理更改的持续集成和持续部署（CI/CD），从而允许在 ALM 工作流中自动测试和提升更新。 Fabric 数据代理的源代码管理目前为预览版。
可以使用两种补充方法来支持 Fabric 数据代理的 ALM：
- Git 集成：将整个工作区与 Git 存储库（Azure DevOps 或 GitHub 作为 Git 提供程序）同步，以启用版本控制、通过分支进行协作以及单个项（包括 Fabric 数据代理）的历史记录跟踪。
- 部署管道：使用内置管道在表示开发、测试和生产阶段的单独工作区之间提升内容。
这些功能共同为 Fabric 数据代理提供端到端 ALM 支持。
重要
此功能目前为预览版。
先决条件
- 付费的 F2 或更高版本的 Fabric 容量，或者每个容量 （P1 或更高版本） 的 Power BI Premium 容量（已启用 Microsoft Fabric）
- Fabric 数据代理租户设置已启用。
- 启用了 AI 的跨地理位置处理 。
- 已启用适用于 AI 的跨地理位置存储。
- 至少有一个包含数据：一个仓库、一个 lakehouse、一个或多个 Power BI 语义模型、一个 KQL 数据库或一个本体。
- 已为 Power BI 语义模型数据源启用通过 XMLA 终结点的 Power BI 语义模型租户切换。
Git 集成
Microsoft Fabric Git 集成将 Fabric 工作区与 Git 存储库同步，使你能够直接在 Fabric 平台中使用现有的开发过程、工具和最佳做法。 它支持 Azure DevOps 和 GitHub，可在工作区级别使用。 从 Fabric 提交更改（包括数据代理配置的更新）时，这些更改将保存为连接的 Git 存储库中的文件。 其关键功能包括：
- 工作区项目的完整备份和版本控制
- Git 中的文件夹结构镜像工作区结构
- 数据代理配置（架构选择、AI 指令、数据源指令、示例查询）存储在专用文件夹中的结构化文件中
- 可以通过历史记录查看不同工作区项目（包括数据代理）的差异、审阅历史，并还原至以前的状态。
- 基于分支的协作（功能分支，主分支）
有关 Git 集成过程的详细信息，可以参考以下资源。
设置与源代码控制的连接
可以从 “工作区设置” 页将 Fabric 工作区连接到 Git 存储库。 通过此连接，可以直接从 Fabric 提交和同步更改。
有关连接到 Azure DevOps 或 GitHub 中的 Git 存储库的详细步骤，请参阅 Git 集成入门 。
连接到 Git 存储库后，工作区项（包括 Fabric 数据代理）会显示在源代码控制面板中。 在左下角的状态栏中，可以看到已连接分支的名称、上次同步的时间和 Git 提交 ID。
- 链接的 Git 存储库显示一个文件夹结构，表示工作区项，包括 Fabric 数据代理及其配置文件。 每个数据代理都存储在其自己的文件夹中，使你能够查看更改、跟踪版本历史记录并使用 Git 工作流，例如创建拉取请求以将更新合并到主分支中。
在 Git 连接的工作区中修改 Fabric 数据代理时，会检测到更改，并且源代码管理窗格中的数据代理状态更改为“未提交的更改”。 这些修改可能包括：
- 更改架构选择。
- 更新 AI 指令或数据源说明。
- 编辑示例查询。
- 发布数据代理或更新其发布说明。
任何更改（无论是功能还是描述性）都会导致数据代理与链接的 Git 存储库不同步。 包含更改的工作区项将显示在“源代码管理”窗格中的“更改”选项卡下。 可以查看这些更改，将其与提交的版本进行比较，并将其提交回 Git 存储库以同步。
- 直接在链接的 Git 存储库（Azure DevOps 或 GitHub）中进行更新时，可以包括修改 AI 说明、更改示例查询或编辑发布说明等作。 然后，可以提交这些更改并将其推送到存储库。 推送更新并在存储库中可用后，Fabric 工作区将检测更新，并在“源代码管理”窗格中显示更新可用通知。 更新的项目（如数据代理）显示在“更新”选项卡下，你可以在其中查看和接受它们。 接受这些更新会将存储库更改应用到工作区项，确保工作区反映 Git 中最新提交的版本。
Git 存储库中的文件夹和文件结构
在以下代码中，你将查看数据代理配置如何存储在 Git 存储库中的结构。 了解此结构对于管理更改和遵循最佳做法非常重要。
根结构
在根目录中，数据代理内容存储在 文件 文件夹下。 在 文件中，可以找到一个 配置 文件夹，其中包含 data_agent.json、 publish_info.json、 草稿文件夹和 已发布文件夹。
在 配置 文件夹中， publish_info.json 包含数据代理的发布说明。 可以更新此文件以更改发布数据代理时显示的说明。
草稿文件夹包含对应于数据代理草稿版本的配置文件，而已发布的文件夹包含数据代理已发布版本的配置文件。 草稿文件夹包含：
-
数据源文件夹 ，其中每个数据源都有一个文件夹供数据代理使用。
-
Lakehouse 或仓库数据源：文件夹名称以
lakehouse-tables-或warehouse-tables-后跟湖屋或仓库的名称开头。 -
语义模型数据源：文件夹名称以
semantic-model-开头，后跟语义模型的名称。 -
KQL 数据库数据源：文件夹名称以
kusto-开头，后跟 KQL 数据库的名称。 -
本体数据源：文件夹名称以
ontology-开头，后跟本体的名称。
-
Lakehouse 或仓库数据源：文件夹名称以
- 包含的
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]。
请执行以下步骤以部署更改：
- 在管道中，转到您要进行部署的阶段（例如，开发）。
- 选择您要在工作区中部署的项。
- 选择“部署”，将其提升到下一阶段。
可以在应用更改之前审查部署计划，以确保只推广预期的更新。 有关详细信息，请参阅 部署管道入门。
注释
在 ALM 方案中，Fabric 数据代理仅支持服务主体。 此支持仅限于支持 ALM 操作（如 Git 集成和部署管道），并且不包括其他 Fabric 数据代理程序功能。 如果需要与 ALM 工作流外部的数据代理交互，则不支持服务主体。
为部署管道发布 Fabric 数据代理
发布 Fabric 数据代理使它可用于所有不同的使用渠道，包括适用于 Power BI 的 Copilot、Microsoft Copilot Studio 和 Azure AI Foundry Services。 若要在这些通道中评估和使用数据代理，必须发布数据代理;即使数据代理位于生产工作区中，也无法访问未发布的数据代理以供使用。 若要按照部署管道遵循最佳做法，请注意：
- 从开发工作区进行发布应仅限于正在处理数据代理开发的授权用户，并希望在不同的使用渠道中评估其性能。 必须限制对此工作区的访问，以便未完成的数据代理或实验性数据代理不会向更广泛的受众公开。
- 最终用户应仅访问从生产工作区发布的数据代理，确保它们与已批准的稳定数据代理版本进行交互。
此方法既支持启用消耗和性能评估的功能要求，又通过使开发和生产环境保持独立来确保适当的访问控制。
最佳做法
- 使用专用分支在数据代理上进行开发工作，并在代码评审后合并到 main。
- 在同一工作区中保留相关资源（数据源、数据代理、笔记本、管道），以便更轻松地升级。
- 在升级到生产环境之前，测试工作区中的测试数据代理更改。
- 使用描述性提交消息使历史记录更易于理解。
- 不要直接更改 Git 存储库中的已发布文件夹。
限制和注意事项
- 只有连接到 Git 存储库的工作区才能使用基于 Git 的 ALM 功能。
- 在 Fabric 数据代理中，服务主体仅在 ALM 方案中得到支持。 如果需要与 ALM 工作流外部的数据代理交互，则不支持服务主体。
- 部署管道要求源工作区和目标工作区位于同一租户中。
- 大量频繁提交可能会影响存储库大小和性能。