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

在 Fabric 数据工厂中,CI/CD(持续集成和持续开发)通过自动处理代码更改(从测试到部署)帮助团队更快、更可靠地工作。

现在,Fabric 支持 CI/CD 的两个关键功能,它与应用程序生命周期管理(ALM)团队建立了合作关系:Git 集成和部署管道。 这些工具允许一次导入和导出工作区资源,因此只能更新所需的资源。

与通常使用 ARM 模板更新整个工厂的 Azure 数据工厂不同,Fabric 的方法可提供更多控制。 无需暂停所有管道即可更新特定管道。 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 存储库时,它会触发 CI/CD 管道。 此集成可确保始终自动测试并部署最新的代码更改。

阶段和作业

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

自动化工作流

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

管道的 Git 集成入门

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

Git 集成的先决条件

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

步骤 1:连接到 Git 存储库

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

  1. 登录到 Fabric 并导航到要连接到 Git 的工作区。

  2. 选择“工作区设置”。

    显示在 Fabric UI 中选择工作区设置的位置的屏幕截图。

  3. 选择“git 集成”。

  4. 选择 Git 提供程序。 目前,Fabric 仅支持 Azure DevOps 或 GitHub。 如果使用 GitHub,则需要选择“添加帐户”来连接 GitHub 帐户。 登录后,选择“连接”,允许 Fabric 访问 GitHub 帐户。

    显示在何处为 Fabric 工作区 Git 集成添加 GitHub 帐户的屏幕截图。

步骤 2:连接到工作区

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

  1. 在下拉菜单中,指定要连接到的分支的以下详细信息:

    1. 对于 Azure DevOps 分支连接,请指定以下详细信息:

      • 组织:Azure DevOps 组织名称。
      • 项目:Azure DevOps 项目名称。
      • 存储库:Azure DevOps 存储库名称。
      • 分支:Azure DevOps 分支名称。
      • 文件夹:Azure DevOps 文件夹名称。
    2. 对于 GitHub 分支连接,请指定以下详细信息:

      • 存储库 URL:GitHub 存储库 URL。
      • 分支:GitHub 分支名称。
      • 文件夹:GitHub 文件夹名称。
  2. 选择“连接并同步”。

  3. 连接后,工作区将显示有关源代码管理的信息,用户可以通过该信息查看连接的分支、分支中每个项的状态以及上次同步的时间。

    显示 Fabric 工作区的屏幕截图,其中包含 Git 状态和管道报告的其他详细信息。

步骤 3:将更改提交至 Git

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

  1. 转到工作区。

  2. 选择“源代码管理”图标。 此图标显示未提交的更改数。

    Fabric 工作区 UI 中的“源代码管理”按钮的屏幕截图。

  3. 从“源代码管理”面板中选择“更改”选项卡。 此时会显示一个列表,其中列出所有已更改的项,并列出一个图标,指示状态为“新”、“已修改”、“冲突” 或“已删除”

  4. 选择想要删除的项目。 若要选择所有项目,检查顶部框。

  5. (可选)在方框中添加提交注释。

  6. 选择“提交”。

    Git 提交的“源代码管理”对话框的屏幕截图。

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

步骤 4:(可选)从 Git 更新工作区

  1. 转到工作区。

  2. 选择“源代码管理”图标。

  3. 从“源代码管理”面板中选择“更新”。 此时会显示一个列表,其中列出自上次更新以来 Git 连接源中分支中所有已更改的项。

  4. 选择“全部更新”。

    显示 Fabric UI 中“源代码管理”对话框的“更新”选项卡的屏幕截图。

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

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

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

部署管道的先决条件

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

步骤 1:创建部署管道

  1. 在“工作区”浮出控件中,选择“部署管道”。

    显示“工作区”浮出控件的屏幕截图,其中显示了 Fabric UI 中的“部署管道”按钮。

  2. 选择“创建管道”或“+ 新建管道”。

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

  1. “创建部署管道”对话框中,输入管道的名称和描述,然后选择“下一步”

  2. 通过定义部署管道所需的阶段来设置部署管道的结构。 默认情况下,管道有三个阶段,分别为开发、测试和生产

    显示默认部署管道阶段的屏幕截图。

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

    显示填充的示例部署管道的屏幕截图。

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

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

步骤 4:部署到空阶段

  1. 处理完一个管道阶段中的内容后,可以将其部署到下一阶段。 在部署内容时,部署管道会提供三个选项:

    • 完整部署:将所有内容部署到目标阶段。
    • 选择性部署:选择要部署到目标阶段的内容。
    • 向后部署:将内容从管道中的后期阶段部署到早期阶段。 目前,仅当目标阶段为空(没有分配给它的工作区)时,才可能进行向后部署。
  2. 选择如何部署内容后,可以查看部署并留下备注

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

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

计划管道 CI/CD 集成

为管道创建计划时,它会自动添加到连接到工作区的 Git 存储库,并将其存储在管道定义的 .schedules 文件中。

构造数据工厂中计划管道的 .schedules 文件的屏幕截图。

已知限制

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

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