选择最适合你的 Fabric CI/CD 工作流选项
本文的目的是根据常见的客户方案，向 Fabric 开发人员介绍在 Fabric 中构建 CI/CD 过程的不同选项。 本文更侧重于 CI/CD 过程的“持续部署”(CD)。 有关“持续集成”(CI) 部分的讨论，请参阅管理 Git 分支。
尽管本文概述了几种不同的选项，但许多组织采取混合方法。
先决条件
若要访问部署管道功能，必须满足以下条件：
必须具有 Microsoft Fabric 订阅
你是 Fabric 工作区的管理员
产品流程
在所有部署方案中，开发过程都是相同的，与如何将新更新发布到生产中无关。 开发人员在使用源代码管理时需要在独立环境中工作。 在 Fabric 中，该环境可以是本地计算机上的 IDE（例如 Power BI Desktop 或 VS Code），也可以是 Fabric 中的其他工作区。 可以在管理 Git 分支中找到有关开发过程的不同注意事项的信息
发布过程
新更新完成且拉取请求 (PR) 合并到团队的共享分支（例如主分支、开发分支等）后，发布过程就会开始。 从此时开始，可以通过不同选项在 Fabric 中生成发布过程。
选项 1 - 基于 Git 的部署
使用此选项，所有部署都源自 Git 存储库。 发布管道中的每个阶段都有一个专用主要分支（在图中，这些阶段分为“开发”阶段、“测试”阶段和“生产”阶段），为 Fabric 中的相应工作区馈送数据。
一旦对开发分支的 PR 获得批准并进行合并，就会执行以下操作：
- 触发发布管道来更新“开发”工作区的内容。 此过程还可能包含一个用来运行单元测试的生成管道，但文件的实际上传是使用 Fabric Git API 直接从存储库上传到工作区中的。 可能需要调用其他 Fabric API 来执行部署后操作，这些操作设置此工作区的特定配置或引入数据。
- 然后为测试分支创建一个 PR。 大多数情况下，PR 是使用发布分支创建的，该分支可以挑选进入下一阶段的内容。 PR 应该包含与团队或组织中的任何其他 PR 相同的审查和批准过程。
- 使用与第一步中所述过程类似的过程，触发另一个生成和发布管道来更新“测试”工作区。
- 使用与步骤 2 中所述过程类似的过程，为生产分支创建 PR。
- 使用与第一步中所述过程类似的过程，触发另一个生成和发布管道来更新“生产”工作区。
何时应考虑使用选项 1？
- 当你想使用 Git 存储库作为单一事实来源和所有部署的源时。
- 当团队按照作为分支策略的 Gitflow（其中包括多个主要分支）进行操作时。
- 从存储库上传的内容会直接进入工作区，因为我们不需要在部署之前生成环境来更改文件。 可以通过在部署后调用 API 或运行工作区中的项来更改此设置。
选项 2 - 使用生成环境进行的基于 Git 的部署
使用此选项，所有部署都源自 Git 存储库所在的分支（主分支）。 发布管道中的每个阶段都有专用的生成和发布管道。 这些管道可能会使用某个生成环境来运行单元测试和脚本，以便在将项上传到工作区之前更改其中的某些定义。 例如，你可能想要更改数据源连接、工作区中项之间的连接或参数值以调整相应阶段的配置。
一旦对开发分支的 PR 获得批准并进行合并，就会执行以下操作：
- 触发生成管道以启动新的生成环境并运行“开发”阶段的单元测试。 然后触发发布管道，以便将内容上传至生成环境，运行脚本以更改部分配置，调整“开发”阶段的配置，并使用 Fabric 的更新项定义 API 将文件上传到工作区中。
- 此过程（包括引入数据和获得发布管理员的批准）完成后，即可创建用于“测试”阶段的下一个生成和发布管道。 这些阶段的创建过程与第一步中描述的过程类似。 对于“测试”阶段，可能需要在部署后进行其他自动或手动测试，以验证是否已做好将更改发布到“生产”阶段的准备。
- 当所有自动和手动测试都完成后，发布管理员即可批准并启动生成和发布管道，进入“生产”阶段。 由于“生产”阶段的配置通常不同于“开发/测试”阶段的配置，因此还必须在部署后测试所做的更改，这很重要。 此外，部署应该根据所做的更改触发更多的数据引入，以最大限度地减少使用者可能无法使用数据的情况。
何时应考虑使用选项 2？
- 当你想使用 Git 作为单一事实来源和所有部署的源时。
- 当团队按照作为分支策略的、基于主干的工作流进行操作时。
- 你需要一个生成环境（带有自定义脚本），以便在部署之前更改特定于工作区的属性，例如 connectionId 和 lakehouseId。
- 你需要一个发布管道（自定义脚本），以便从 git 检索项内容，并调用相应的 Fabric 项 API 来创建、更新或删除已修改的 Fabric 项。
选项 3 - 使用 Fabric 部署管道进行部署
使用此选项，Git 仅在“开发”阶段之前处于连接状态。 从“开发”阶段开始，部署使用 Fabric 部署管道直接在“开发/测试/生产”工作区之间进行。 开发人员可以使用部署管道 API 将部署编排为其 Azure 发布管道或 GitHub 工作流的一部分，虽然该工具本身是 Fabric 内部的工具。 这些 API 使团队能够通过使用自动化测试（可以在工作区本身中完成，也可以在“开发”阶段之前完成）、审批等方式生成与其他选项中的相应过程类似的生成和发布过程。
一旦对主分支的 PR 获得批准并进行合并，就会执行以下操作：
- 触发生成管道，该管道使用 Fabric Git API 将所做的更改上传到“开发”阶段。 如有必要，该管道可以触发其他 API，以在“开发”阶段启动部署后操作/测试。
- “开发”部署完成后，就会启动发布管道，以将所做的更改从“开发”阶段部署到“测试”阶段。 部署后应进行自动和手动测试，以确保在将所做的更改投入生产之前对其进行充分的测试。
- 当测试完成且发布管理员批准到“生产”阶段的部署后，就会启动到“生产”阶段的发布并完成部署。
何时应考虑使用选项 3？
- 当你仅将源代码管理用于开发目的且首选在发布管道的各个阶段之间直接部署更改时。
- 当部署规则、自动绑定和其他可用 API 足以管理发布管道各阶段之间的配置时。
- 当你想要使用 Fabric 部署管道的其他功能（例如查看 Fabric 中的更改、部署历史记录等）时。
- 此外还应考虑到，Fabric 部署管道中的部署具有线性结构，并且需要其他权限来创建和管理管道。
选项 4 - Fabric 中 ISV 的 CI/CD（管理多个客户/解决方案）
此选项与其他选项不同。 它与在 Fabric 上为客户生成 SaaS 应用程序的独立软件供应商 (ISV) 最为相关。 ISV 通常为每个客户提供单独的工作区，所拥有的工作区可能多达数百或数千个。 当提供给每个客户的分析结构相似且是现成的时，建议采用集中式开发和测试过程，只有在“生产”阶段才针对每个客户对其进行拆分。
此选项基于选项 2。 一旦对主分支的 PR 获得批准并进行合并，就会执行以下操作：
- 触发生成管道以启动新的生成环境并运行“开发”阶段的单元测试。 测试完成后，将触发发布管道。 该管道可以将内容上传至生成环境，运行脚本以更改部分配置，调整“开发”阶段的配置，然后使用 Fabric 的更新项定义 API 将文件上传到工作区中。
- 此过程（包括引入数据和获得发布管理员的批准）完成后，即可启动用于“测试”阶段的下一个生成和发布管道。 此过程与第一步中描述的过程类似。 对于“测试”阶段，可能需要在部署后进行其他自动或手动测试，以验证是否已做好将更改高质量地发布到“生产”阶段的准备。
- 所有测试都通过且审批过程完成后，即可启动到“生产”客户的部署。 每个客户都有自己的发布和自己的参数，因此，其特定的配置和数据连接可以在相关客户的工作区中进行。 配置更改可通过生成环境中的脚本进行，也可在部署后通过 API 进行。 所有发布都可以并行进行，因为它们彼此之间既不相关，也不依赖。
何时应考虑使用选项 4？
- 你是一家在 Fabric 上构建应用程序的 ISV。
- 你为每个客户使用不同的工作区来管理应用程序的多租户。
- 为了实现进一步的分离或针对不同客户进行特定测试，可能需要在开发或测试的早期阶段采用多租户。 在这种情况下，应考虑到使用多租户时所需的工作区数量会显著增加。
总结
本文总结了想要在 Fabric 中构建自动 CI/CD 过程的团队的主要 CI/CD 选项。 虽然我们概述了四个选项，但现实生活中的约束和解决方案体系结构可能导致混合选项或完全不同的选项是更合适的选择。 你可以将本文作为指南来了解不同的选项及其构建方式，但不必只选择其中一个选项。
某些方案或特定项可能存在限制，可能会阻止你采用其中任何一种方案。
工具也是如此。 虽然我们在这里提到了各种不同的工具，但你可以选择能够提供相同级别功能的其他工具。 应考虑到 Fabric 与某些工具的集成更佳，因此选择其他工具会导致更多限制，因而需要不同的解决方法。