Microsoft Fabric 数据工厂中管道的 CI/CD

项目
11/26/2024

在 Fabric 数据工厂中，持续集成和持续开发 (CI/CD) 会自动执行代码更改的集成、测试和部署，以确保高效可靠的开发。

在 Fabric 中，我们目前与应用程序生命周期管理 (ALM) 团队合作支持两项功能：Git 集成和部署管道。这些功能允许用户导入/导出带有单独更新的工作区资源。

Fabric 数据工厂 CI/CD 解决方案与 Azure 数据工厂模型有所不同，后者首选使用 ARM 模板导出方法进行整个工厂的更新。此方法中的更改允许客户选择性地选择要更新的管道，而无需暂停整个工厂。 Git 集成（自带 Git）和部署管道（内置 CI/CD）都使用将单个工作区与单个环境关联的概念。需要将不同的工作区映射到不同的环境，例如开发、测试和生产环境。

开发人员为何要使用 CI/CD

CI/CD 是实现软件交付自动化的一种做法，它解决了一些突出的痛点：

手动集成问题：如果没有 CI/CD，手动集成代码更改可能会导致冲突和错误，从而减慢开发速度。
开发延迟：手动部署非常耗时且容易出错，导致交付新功能和更新时出现延迟。
环境不一致：不同的环境（开发、测试和生产）可能存在不一致，导致难以调试的问题。
缺乏可见性：如果没有 CI/CD，跟踪更改和了解代码库的状态可能具有挑战性。

了解 CI/CD、Git 和部署管道

CI/CD 由持续集成和持续部署组成。

持续集成 (CI)

开发人员经常提交到 Git 托管的主分支，从而触发自动化测试和集成构建。 Git 会跟踪更改，实现对新提交内容的自动提取和测试。

持续部署 (CD)

重点介绍如何通过部署管道中的结构化部署阶段将已验证的更改部署到生产开发。

Git 与数据工厂管道集成

Git 是一种版本控制系统，使开发人员能够跟踪其代码库（如果是管道，则是 JSON 代码定义）中的更改，并与其他人协作。它提供一个集中的存储库，用于存储和管理代码更改。目前，Git 在 Fabric 中通过 GitHub 或 Azure DevOps 受到支持。使用 Git 时，有几个关键的工作流要点需要理解。

主分支：主分支（有时名为“主要分支”）保存生产就绪代码。
功能分支：这些分支与主分支分开，支持进行独立开发而不更改主分支。
拉取请求 (PR)：PR 支持用户在集成之前提出、审查和讨论更改。
合并：在更改获得批准时会进行合并。 Git 会集成这些更改，不断更新项目。

Git 的部署管道

部署管道与 Git 紧密集成。当开发人员将代码更改推送到 Git 存储库时，它会触发 CI/CD 管道。此集成可确保始终自动测试并部署最新的代码更改。

阶段和作业

部署管道包含多个阶段，每个阶段包含多个作业。通常，这些阶段分为 3 个环境：开发（编译代码）、测试（运行测试）和生产（部署应用程序）。管道会经历这些阶段，确保以受控方式全面测试和部署代码。

自动化工作流

部署管道可自动完成生成、测试和部署代码的整个过程。这种自动化可降低人为错误的风险，加快开发过程，并确保代码更改一致且可靠地交付到生产环境。

开始使用适用于数据工厂管道的 Git 集成

按照以下步骤为数据工厂中的管道设置 Git 集成：

Git 集成的先决条件

若要使用 Microsoft Fabric 工作区访问 Git，请确保满足以下针对 Fabric 和 Git 的先决条件。

Power BI Premium 许可证或 Fabric 容量。
从管理门户启用以下租户切换：
- 用户可以创建 Fabric 项
- 用户可以将工作区项与 Git 存储库同步
- （仅适用于 GitHub 用户）用户可以将工作区项与 GitHub 存储库同步
Azure DevOps 或 GitHub 帐户。
- 对于 Azure DevOps 帐户：
  - 向使用 Fabric 工作区的同一用户注册的活动 Azure 帐户。创建一个免费帐户。
  - 对现有存储库的访问权限
- 对于 GitHub 帐户：
  - 一个有效的 GitHub 帐户。创建一个免费帐户。
  - 在存储库权限下对内容的读取和写入权限的细粒度令牌，或者启用了存储库范围的 GitHub 经典令牌。

步骤 1：连接到 Git 存储库

若要在 Fabric 中使用与数据工厂管道的 Git 集成，首先需要连接到 Git 存储库，如此处所述。

登录到 Fabric 并导航到要连接到 Git 的工作区。
选择“工作区设置”。
选择“git 集成”。
选择 Git 提供程序。目前，Fabric 仅支持 Azure DevOps 或 GitHub。如果使用 GitHub，则需要选择“添加帐户”来连接 GitHub 帐户。登录后，选择“连接”，允许 Fabric 访问 GitHub 帐户。

步骤 2：连接到工作区

连接到 Git 存储库后，需要连接到工作区，如此处所述。

在下拉菜单中，指定要连接到的分支的以下详细信息：
1. 对于 Azure DevOps 分支连接，请指定以下详细信息：
  - 组织：Azure DevOps 组织名称。
  - 项目：Azure DevOps 项目名称。
  - 存储库：Azure DevOps 存储库名称。
  - 分支：Azure DevOps 分支名称。
  - 文件夹：Azure DevOps 文件夹名称。
2. 对于 GitHub 分支连接，请指定以下详细信息：
  - 存储库 URL：GitHub 存储库 URL。
  - 分支：GitHub 分支名称。
  - 文件夹：GitHub 文件夹名称。
选择“连接并同步”。
连接后，工作区将显示有关源代码管理的信息，用户可以通过该信息查看连接的分支、分支中每个项的状态以及上次同步的时间。

步骤 3：将更改提交至 Git

连接到 Git 存储库和工作区后，可以提交对 Git 的更改，如下所示。

转到工作区。
选择“源代码管理”图标。此图标显示未提交的更改数。
从“源代码管理”面板中选择“更改”选项卡。此时会显示一个列表，其中列出所有已更改的项，并列出一个图标，指示状态为“新”、“已修改”、“冲突” 或“已删除”。
选择想要删除的项目。若要选择所有项目，检查顶部框。
（可选）在方框中添加提交注释。
选择“提交”。

提交更改后，已提交的项将从列表中删除，工作区将指向同步到的新提交。

步骤 4：（可选）从 Git 更新工作区

转到工作区。
选择“源代码管理”图标。
从“源代码管理”面板中选择“更新”。此时会显示一个列表，其中列出自上次更新以来 Git 连接源中分支中所有已更改的项。
选择“全部更新”。

成功更新后，会删除项列表，工作区将指向其同步到的新提交。

开始使用适用于 Git 的部署管道

按照以下步骤将 Git 部署管道与 Fabric 工作区结合使用。

部署管道的先决条件

在开始之前，请务必设置以下先决条件：

活动的 Microsoft Fabric 订阅。
Fabric 工作区的管理员访问权限。

步骤 1：创建部署管道

在“工作区”浮出控件中，选择“部署管道”。
选择“创建管道”或“+ 新建管道”。

步骤 2：为管道命名并分配阶段

在“创建部署管道”对话框中，输入管道的名称和描述，然后选择“下一步”。
通过定义部署管道所需的阶段来设置部署管道的结构。默认情况下，管道有三个阶段，分别为开发、测试和生产。

可以添加另一个阶段、删除阶段或在框中键入新名称对阶段重命名。完成后，选择“创建”（或“创建并继续”）。

步骤 3：将工作区分配给部署管道

创建管道后，需要将想要管理的内容添加到管道。向管道添加内容是通过将工作区分配到管道阶段来完成的。可以将工作区分配到任何阶段。按照说明将工作区分配给管道。

步骤 4：部署到空阶段

处理完一个管道阶段中的内容后，可以将其部署到下一阶段。在部署内容时，部署管道会提供三个选项：
- 完整部署：将所有内容部署到目标阶段。
- 选择性部署：选择要部署到目标阶段的内容。
- 向后部署：将内容从管道中的后期阶段部署到早期阶段。目前，仅当目标阶段为空（没有分配给它的工作区）时，才可能进行向后部署。
选择如何部署内容后，可以查看部署并留下备注。

步骤 5：将内容从一个阶段部署到另一个阶段

在管道阶段中有内容后，即使下一阶段工作区包含内容，也可以将其部署到下一阶段。将覆盖配对的项。有关此过程的详细信息，请参阅将内容部署到现有工作区部分。
可以查看部署历史记录，看到最后一次将内容部署到每个阶段的时间。若要在部署之前检查两个管道之间的差异，请参阅比较不同部署阶段的内容。

已知限制

下面的已知限制适用于 Microsoft Fabric 数据工厂中的管道的 CI/CD：

工作区变量：CI/CD 当前不支持工作区变量。
Git 集成有限支持：目前，Fabric 仅支持 Git 与 Azure DevOps 和 GitHub 的集成。建议使用 Azure DevOps Git 集成，因为 GitHub Git 集成具有更多限制。
使用 OAuth 连接器的管道活动：对于 MS Teams 和 Outlook 连接器，在部署到更高级别的环境时，当前的一个限制是用户必须手动打开每个管道并登录到每个活动。
调用数据流的管道：当调用数据流的管道被提升时，它仍将引用上一个工作区中的数据流，但这是错误的操作。发生此行为的原因是部署管道中当前不支持数据流。

通过

Microsoft Fabric 数据工厂中管道的 CI/CD

开发人员为何要使用 CI/CD