管理 Microsoft Fabric 工作区中的分支

本文的目的是根据常见的客户方案，向 Fabric 开发人员介绍在 Fabric 中构建 CI/CD 过程的不同选项。 本文更侧重于 CI/CD 过程的持续集成 (CI) 部分。 有关持续交付 (CD) 部分的讨论，请参阅管理部署管道。

本文概述了一些不同的集成选项，但许多组织会使用它们的组合。

先决条件

若要将 Git 与 Microsoft Fabric 工作区集成，需要在 Fabric 和 Git 中设置以下先决条件。

Fabric 先决条件

若要访问 Git 集成功能，需要以下项之一：

• Power BI Premium 许可。 Power BI Premium 许可证仅支持所有 Power BI 项。
• Fabric 容量。 需要使用结构容量才能使用所有受支持的 Fabric 项。 如果没有，可以注册免费试用版。

此外，必须从管理员门户启用以下租户开关：

• 用户可以创建 Fabric 项
• 用户可以将工作区项与 Git 存储库同步
• 仅适用于 GitHub 用户：用户可以将工作区项与 GitHub 存储库同步

租户管理员、容量管理员或工作区管理员可以根据组织的设置启用这些开关。

Git 先决条件

Azure DevOps 和 GitHub 目前支持 Git 集成。 若要使用 Git 与 Fabric 工作区集成，需要在 Azure DevOps 或 GitHub 中满足以下先决条件：

Azure DevOps

• 向使用 Fabric 工作区的同一用户注册的活动 Azure 帐户。 创建一个免费帐户。
• 访问现有存储库。

GitHub

• 一个有效的 GitHub 帐户。 创建 GitHub 帐户。

• 以下个人访问令牌之一：

  • 存储库权限下具有“内容”读取和写入权限的精细令牌（推荐使用）：

    

    若要将此令牌用于 GitHub Enterprise，请按照以下说明进行操作。

  • 创建启用了存储库作用域的 GitHub 经典令牌：

    

产品流程

Fabric 工作区是访问实时项的共享环境。 直接在工作区中所做的任何更改都会覆盖并影响所有其他工作区用户。 因此，Git 最佳做法是让开发人员在共享工作区之外独立工作。 开发人员可通过两种方式在自己的受保护工作区中工作。

• 使用客户端工具进行开发，例如用于报表和语义模型的 Power BI Desktop 或用于笔记本的 VS Code。
• 在单独的 Fabric 工作区中开发。 每个开发人员都有自己的工作区，在其中连接自己的单独分支，将内容同步到该工作区，然后提交回分支。

若要使用 Git 集成处理分支，请先将共享开发团队的工作区连接到单个共享分支。 例如，如果团队使用一个共享工作区，请将其连接到团队存储库中的主分支，并在工作区和存储库之间同步。 如果团队的工作流具有多个共享分支，如开发/测试/生产分支，则每个分支都可以连接到不同的工作区。

然后，每个开发人员都可以选择要在其中工作的独立环境。

方案 1 - 使用客户端工具进行开发

如果正在开发的项目在其他工具中可用，则可以直接在客户端工具中处理它们。 并非所有项目都可以在每个工具中使用。 仅在 Fabric 中可用的项目需要在 Fabric 中开发。

使用客户端工具（如 Power BI Desktop）的开发人员的工作流应如下所示：

1. 将存储库克隆到本地计算机。 （此步骤只需执行一次。）

2. 使用 PBIProj 的本地副本在 Power BI Desktop 中打开项目。

3. 进行更改，并将更新后的文件保存在本地。 提交到本地存储库。

4. 准备就绪后，推送分支并提交到远程存储库。

5. 通过将新分支连接到单独的工作区，并使用源代码管理面板中的“全部更新”按钮上传语义模型和报表，针对其他项或更多数据测试更改。 在合并到主分支之前，执行任何测试或配置更改。

   如果工作区中不需要测试，开发人员可以直接将更改合并到主分支中，而无需其他工作区。

6. 合并更改后，系统会提示共享团队的工作区接受新提交。 更改将更新到共享工作区中，每个人都可以看到这些语义模型和报表的更改。

有关如何在 git 中使用新 Power BI Desktop 文件格式的具体指南，请参阅源代码格式。

方案 2 - 使用另一个工作区进行开发

对于在 Web 中工作的开发人员，流程如下所示：

1. 从“源代码管理”菜单的“分支”选项卡中，选择“将范围扩大到新工作区”。

   

2. 指定分支和工作区的名称。 基于连接到当前工作区的分支创建的新分支。

   

3. 选择“扩展延伸”。

   Fabric 将创建新的工作区和分支。 你将自动进入新工作区。

   工作区与功能分支同步，并将成为要使用的独立环境，如图所示。 现在即可在这个新的独立环境中工作。 同步可能需要几分钟时间。 有关扩展延伸的详细信息，请参阅故障排除提示。

   

4. 保存更改并将其提交到功能分支。

5. 准备就绪后，创建主分支的 PR。 评审和合并流程通过 Azure Repos 根据团队为该存储库定义的配置来完成。

评审和合并完成后，将为主分支创建新的提交。 此提交会提示用户使用合并的更改更新开发团队工作区中的内容。

有关详细信息，请参阅扩展延伸限制。

发布过程

新更新完成拉取请求过程并合并到团队的共享分支（如 Main、Dev 等）后，发布过程将开始。 从此时开始，我们将概述在 Fabric 中构建发布过程的不同选项。 可以在管理部署管道中找到发布过程的不同注意事项。

切换分支

如果工作区已连接到 Git 分支，并且你想要切换到另一个分支，则可以从“源代码管理”面板设置快速执行此操作，而无需断开连接和重新连接。
切换分支时，工作区与新分支同步，工作区中的所有项都会被覆盖。 如果每个分支中都存在同一项的不同版本，则替换该项。 如果某个项位于旧分支中，但不在新分支中，则会被删除。 若要在分支之间切换，请执行以下步骤：

1. 从“源代码管理”菜单的“分支”选项卡中，选择“切换分支”。

   

2. 指定要连接到或创建新分支的分支。 此分支必须包含与当前分支相同的目录。

3. 选择“切换分支”。

如果工作区中有任何未提交的更改，则无法切换分支。 选择“取消”，在切换分支之前返回并提交更改。

若要在保持现有工作区状态的同时将当前工作区连接到新分支，请选择“签出新分支”。 通过在 Git 中解决冲突了解有关签出新分支的详细信息。

相关内容

• 处理错误和冲突
• Git 集成的最佳做法