通过

用于验证的 Power BI Project (PBIP) 和 Azure DevOps 生成管道

  • 项目

将 Fabric Git 集成与 Azure DevOps 相结合，可将工作区连接到 Azure DevOps 存储库中的分支，并在它们之间自动同步。

将 PBIP 格式与 Azure DevOps 集成后，可以使用 Azure Pipelines 自动执行持续集成/持续部署 (CI/CD) 管道。 这些管道处理 PBIP 元数据文件，并将一系列质量检查应用于开发，然后再将其部署到生产系统。

本文重点介绍持续集成，并介绍如何创建 Azure DevOps 管道，以保证执行 Fabric 工作区中所有语义模型和报表的最佳做法。 通过实施自动化质量测试，可以预防常见错误，并提高团队效率。 例如，此方法可确保新团队成员遵守语义模型和报表开发的既定标准。

在项目概述和 Fabric Git 集成概述中详细了解 PBIP 和 Fabric Git 集成。

下图演示了端到端场景，其中包含两个开发工作流，用于触发 Azure DevOps 管道来验证开发质量。 该管道会执行会执行以下操作：

显示 DevOps 管道工作流的关系图。

  1. 用户 1 使用 Power BI Desktop 进行开发。

    1. 使用 VS Code 从主分支创建分支（功能/数据集更改）
    2. 使用 Power BI Desktop 更改语义模型
    3. 使用 VS Code 将更改提交到远程存储库分支
    4. 使用 Azure DevOps 创建主分支的拉取请求

  2. 同时，用户 2 使用另一个 Fabric 工作区进行开发。

    1. 使用 Fabric Git 从主分支创建分支（功能/报表更改）
    2. 在 Fabric 工作区中更改报表
    3. 使用 Fabric Git 将更改提交到远程存储库分支
    4. 使用 Azure DevOps 创建主分支的拉取请求

  3. 团队主管会审核拉取请求，并使用 Fabric Git 将更改同步到团队工作区。

  4. 拉取请求会触发 Azure DevOps 管道来检查语义模型和报表开发质量。

注意

在此示例中，管道使用两个开源社区工具，使开发人员能够将（可自定义的）最佳做法规则应用于 Power BI Project 文件夹中语义模型和报表的元数据：

与本文中的示例类似的方法适用于其他社区工具。 本文不深入探讨以前提及的社区工具的具体内容，也不探讨规则创建和编辑。 有关这些主题的详细信息，请参阅提供的链接。 本文重点关注在源代码管理和 Fabric 工作区之间建立质量门的过程。 请务必注意，引用的社区工具由第三方参与者开发，Microsoft 不提供支持或文档。

步骤 1 - 将 Fabric 工作区连接到 Azure DevOps

将 Fabric 工作区连接到 Azure DevOps：

显示与 DevOps 的 Git 连接的屏幕截图。

当 Fabric Git 集成完成导出工作区项时，Azure DevOps 分支将包含工作区中每个项的文件夹：

显示 Azure DevOps 分支的屏幕截图，其中包含不同工作区项的文件夹。

步骤 2 - 创建并运行 Azure DevOps 管道

创建新的管道：

  1. 在左侧导航菜单的“管道”选项卡中，选择“创建管道”：

    显示如何创建管道的屏幕截图。

  2. 选择 Azure Repos Git 并选择第一个存储库（连接到 Fabric 工作区的相同存储库）：

    显示选择 Azure 存储库 Git 作为管道代码源的屏幕截图。

    显示选择 Demo-ADObuild 存储库的屏幕截图。

  3. 选择“初学者管道”。

    显示已选择“初学者管道”图标的屏幕截图。

    以下 YAML 代码显示在编辑器中：

    显示默认 YAML 代码的屏幕截图。

  4. 将 Power BI 开发人员模式管道中的 YAML 代码复制并粘贴到创建的管道中：

    显示要添加的 YAML 代码的屏幕截图。

    显示 YAML 代码的第二部分的屏幕截图。

  5. 选择“保存并运行”，将新管道提交到存储库。

    YAML 代码评审的屏幕截图。

    显示选择“保存并运行”的屏幕截图。

Azure DevOps 运行该管道并并行启动两个生成作业：

显示正在运行管道的 Azure DevOps 的屏幕截图。

  • Build_Datasets
    • 下载表格编辑器二进制文件。
    • 下载最佳做法分析器默认规则。 若要自定义规则，请将 Rules-Dataset.json 添加到存储库的根目录中。
    • 循环浏览所有语义模型项文件夹并运行表格编辑器 BPA 规则。
  • Build_Reports
    • 下载 PBI 检查器二进制文件。
    • 下载 PBI 检查器默认规则。 若要自定义规则，请将 Rules-Report.json 添加到存储库的根目录中。
    • 循环浏览所有报表项文件夹并运行 Power BI 检查器规则。

完成后，Azure DevOps 会创建一个报表，其中显示了它遇到的所有警告和错误：

显示错误报表的屏幕截图。

选择链接以打开两个作业的更详细视图：

显示“查看日志”按钮的屏幕截图。

显示展开的错误日志的屏幕截图。

如果报表或语义模型使具有较高严重性级别的规则失败，则生成会失败，并突出显示错误：

显示荧光笔错误的屏幕截图。

步骤 3 - 定义分支策略

管道启动并运行后，在主分支上启用分支策略。 此步骤可确保不会直接提交到主分支中。 始终需要有“拉取请求”才能将更改合并回主分支，并且可以将管道配置为随每个拉取请求运行。

  1. 选择“分支”>“主分支”>“分支策略”：

    显示分支策略的屏幕截图。

  2. 将创建的管道配置为分支的生成策略：

    显示生成策略 UI 的屏幕截图。

    显示生成策略 UI 的第二部分的屏幕截图。

步骤 4 - 创建拉取请求

如果返回到 Fabric 工作区，请修改其中一个报表或语义模型，并尝试提交更改，则将收到以下错误：

显示“无法提交更改”错误的屏幕截图。

只能通过拉取请求对主分支进行更改。 若要创建拉取请求，请签出要在其进行更改的新分支：

直接从 Fabric 工作区创建分支：

  1. 在“源代码管理”窗格中，选择“签出新分支”并为分支提供名称。

    显示用于签出新分支的源代码管理屏幕的屏幕截图。

    显示如何签出新分支的屏幕截图。

    或者，可以选择在单独的隔离工作区或 Power BI Desktop 中进行开发。 有关详细信息，请参阅使用其他工作区进行开发

  2. 将更改提交到此新分支。

    显示提交对分支的更改的屏幕截图。

  3. 提交后，在 Azure DevOps 门户的主分支中创建拉取请求。

    显示新建拉取请求的屏幕截图。

    显示已创建的拉取请求的屏幕截图。

拉取请求工作流不仅允许验证和查看更改，还可以自动触发管道。

显示报表更改的屏幕截图。

如果其中一项规则存在高严重性错误，则无法完成拉取请求以及将更改合并回主分支。

已完成拉取请求的屏幕截图。

在博客文章中详细了解 PBIP 和 Fabric Git 集成。