通过

Power BI 实现规划：部署内容

  • 项目

注意

本文构成了 Power BI 实现规划 系列文章的一部分。 本系列主要介绍 Microsoft Fabric中的 Power BI 体验。 有关本系列的简介，请参阅 Power BI 实现规划。

本文可帮助你将内容部署为管理内容生命周期的一部分。 它主要针对：

  • Fabric 管理员：负责监督组织的 Fabric 的管理员。 结构管理员可能需要与其他管理员协作，例如监督 Microsoft 365 或 Azure DevOps 的人员。
  • 卓越中心（COE）和 BI 团队：负责监督组织中的 Power BI 的团队。 这些团队包括决定如何管理 Power BI 内容的生命周期的决策者。 这些团队还可以包括发布经理、处理内容发布的生命周期，以及创建和管理有效使用和支持生命周期管理所需的组件工程师。
  • 内容创建者和内容所有者：创建要发布到 Fabric 门户的内容以与他人共享的用户。 这些人员负责管理其创建的 Power BI 内容的生命周期。

生命周期管理包括用于处理内容创建到最终停用的过程和做法。 在生命周期管理 的第三阶段，您需要验证内容更改，此过程涉及由内容创建者和用户执行的验证。 第四阶段部署内容供使用者使用。

若要与使用者共享 Power BI 内容，应首先将内容发布到 Fabric 工作区（或 部署）。 部署内容还涉及在环境之间移动该内容，例如从开发工作区部署到测试工作区，或从测试工作区部署到生产工作区。

下图描述了 Power BI 内容的生命周期，其中突出显示了部署内容的第四阶段。

关系图显示了 Power BI 内容生命周期。第 4 阶段（即内容部署）突出显示。

注意

有关内容生命周期管理的概述，请参阅本系列 中的第一篇文章。

本文重点介绍在整个生命周期内部署内容的关键注意事项和决策。 有关如何部署内容的更多指南，请参阅：

在内容生命周期中，在两个主要点部署内容：

  • 将内容发布到开发工作区时。 此时，将发布内容以验证更改。
  • 在两个工作区之间推广内容（例如将内容从开发工作区提升到测试工作区）时。 此时，您可以在内容准备好进入下一阶段（例如，准备好测试新内容）时进行部署。

以下部分概述了发布或推广内容时可以使用的方法。

决定如何发布内容

在本地计算机上开发内容时，需要在 Fabric 门户中将该内容发布到开发工作区。 通常在需要对 所做的更改进行验证时发布此内容。

注意

在本文中，我们将“发布”内容称为开发工作区的初始部署。 但是，原则上，发布内容与部署内容相同。

在 Fabric 门户中创建的内容（例如数据流、仪表板和记分卡）直接在开发工作区中创建，无需发布。

以下部分介绍了发布内容时可以使用的不同方法。

使用 Power BI Desktop 发布

Power BI Desktop 允许用户 将语义模型和报表从本地计算机发布到 Fabric 门户中的工作区。 此方法是发布内容的最简单方法;但是，它不能自动化。

关系图显示了关于从 Power BI Desktop 发布的方法 1。接下来将介绍关系图中的项。

请考虑在以下情况下使用此方法：

  • 内容创建者更喜欢手动控制发布到 Fabric 门户的内容。
  • 内容创建者使用 Power BI Desktop 开发和管理内容。
  • 内容创建者不熟悉 Azure DevOps 或 Git。
  • 内容仅包含语义模型或报表。

使用第三方工具进行发布

第三方工具允许内容创建者使用工作区 XMLA 读/写终结点发布语义模型。 例如，内容创建者使用表格编辑器来开发和管理模型元数据，例如 TMDL（表格模型定义语言）或 .bim 文件。

关系图显示了方法 2，这是关于从第三方工具发布。接下来将介绍关系图中的项。

提示

有关如何使用第三方工具部署语义模型的详细信息，请参阅 高级数据模型管理使用方案。

有关如何启用和使用 XMLA 读/写终结点的详细信息，请参阅 与 XMLA 终结点的语义模型连接。

请考虑在以下情况下使用此方法：

  • 内容创建者更喜欢手动控制发布到 Fabric 门户的内容。
  • 内容创建者使用第三方工具开发和管理内容。
  • 内容将发布到使用 Premium Per User (PPU)、高级容量或 Fabric 容量许可模式的工作区。
  • 内容创建者不熟悉 Azure DevOps 或 Git。
  • 内容仅包含语义模型。

使用刷新后的 OneDrive 进行发布

OneDrive 允许自助服务内容创建者使用 OneDrive 刷新自动将语义模型或报表发布到 Fabric 门户中的工作区。 内容创建者可以将 Power BI Desktop （.pbix） 文件保存到 OneDrive 中的共享库。 共享库也可以是 SharePoint 或 Microsoft Teams 文档库。

关系图显示方法 3，即使用 OneDrive 刷新进行发布。接下来将介绍关系图中的项。

提示

有关如何将 OneDrive for Work and School 与 Power BI 内容配合使用的详细信息，请参阅 自助服务内容发布使用方案。

有关如何设置 OneDrive 刷新的详细信息，请参阅 刷新存储在 OneDrive 或 SharePoint Online 上的语义模型。

请考虑在以下情况下使用此方法：

  • 内容创建者希望自动将内容发布到 Fabric 门户。
  • 内容创建者不熟悉 Azure DevOps 或 Git。
  • 内容创建者使用 OneDrive 或 SharePoint 对内容执行版本控制。
  • 内容创建者将语义模型和报表保存为 .pbix 文件。
  • 内容仅包含语义模型或报表。

使用 Fabric Git 集成进行发布

Fabric Git 集成 是 Fabric 功能的独占特性，允许内容创建者将分支从远程 Git 存储库同步到 Fabric 工作区。 可以将 Git 集成与 Azure DevOps 结合使用来同步 Azure Repos 中的内容，也可以使用 Azure Pipelines 部署内容（下一部分所述）。

注意

Azure DevOps 是一套与 Power BI 和 Fabric 集成的服务，可帮助规划和协调内容生命周期管理。 以这种方式使用 Azure DevOps 时，通常会利用以下服务：

  • Azure Repos：允许创建和使用远程 Git 存储库，这是用于跟踪和管理内容更改的远程存储位置。
  • Azure Pipelines：允许创建和使用一组自动化任务来处理、测试和将内容从远程存储库部署到工作区。
  • Azure 测试计划：允许您设计测试以验证解决方案，并通过 Azure Pipelines 自动执行质量控制。
  • Azure Boards：允许使用板将任务和计划作为工作项进行跟踪，以及链接或引用其他 Azure DevOps 服务的工作项。
  • Azure Wiki：允许你与其团队共享信息，以理解和参与内容。

总之，已提交并推送到远程存储库的内容将通过此同步过程自动发布到工作区。 此方法的主要好处是，它允许将 源代码管理 进程与内容发布结合使用。 例如，可以更轻松地回滚解决方案的更改或整个版本。

关系图显示方法 4，即使用 Fabric Git 集成进行发布。接下来将介绍关系图中的项。

提示

有关如何使用 Fabric Git 集成部署 Power BI 内容的详细信息，请参阅 企业内容发布使用情况方案。

有关如何设置 Git 集成的详细信息，请参阅 教程：Fabric 和 Power BI Desktop 项目的生命周期管理：Git 集成。

请考虑在以下情况下使用此方法：

  • 内容创建者熟悉 Azure DevOps 和 Git。
  • 内容创建者使用 Azure DevOps 进行协作和源代码管理。
  • 内容创建者将语义模型和报表另存为 Power BI 项目（.pbip） 文件。
  • 内容将发布到 Fabric 容量上的工作区。
  • 内容由 Git 集成功能支持的项类型组成。
  • 内容没有敏感度标签。

注意

如何使用 Git 集成来部署和管理内容在很大程度上取决于分支和合并策略，这些策略是在生命周期管理的第二阶段决定的。

使用 Azure Pipelines 进行发布

Azure Pipelines 以编程方式自动执行内容测试、管理和部署。 运行管道时，管道中的步骤会自动执行。 与其他方法相比，Azure Pipelines 更为复杂，需要更多时间和精力进行设置，但它允许最控制和灵活性来协调部署过程。

关系图显示了方法 5，即在 Azure DevOps 中使用 Azure Pipelines 进行发布。接下来将介绍关系图中的项。

提示

可以使用 Azure Pipelines 和 Power BI REST API 将内容部署到不在 Fabric 或高级容量上的工作区。 但是，Fabric REST API 仅适用于 Fabric，XMLA 终结点仅适用于 Fabric 或高级容量。

有关如何使用 Azure Pipelines 部署 Power BI 内容的详细信息，请参阅 企业内容发布使用情况方案。

有关如何将 Azure DevOps 与 Power BI 集成的详细信息，请参阅 Power BI Desktop 项目 Azure DevOps 集成 和 生成管道。

请考虑在以下情况下使用 Azure Pipelines 来协调内容部署：

  • 内容创建者熟悉 Azure DevOps 和 Fabric REST API。
  • 内容创建者使用 Azure DevOps 进行协作和源代码管理。
  • 内容创建者不使用 Fabric Git 集成。

Azure Pipelines 和其他基于代码的工具可以使用以下一个或多个 API 或终结点以编程方式部署内容：

  • Power BI REST API：可以使用不同的 Power BI REST API 终结点来部署内容。 Power BI REST API 仅支持 Power BI 项类型。
    • 导入：可以通过 Power BI REST API 将有效源文件（如 .pbix 文件）导入到工作区，从而发布受支持的项目。
    • 部署：可以部署受支持的项，如果它们是部署管道中的阶段，则将它们从一个工作区推广到另一个工作区。
  • Fabric REST API：可以使用不同的 Fabric REST API 终结点来部署内容。 Fabric REST API 支持 Power BI 和 Fabric 项类型。
    • 创建：可以使用 Fabric REST API 和有效的 项定义来创建受支持的项。
    • 从 Git 更新：可以通过使用 Git 集成，利用连接的远程存储库中的内容更新工作区。
  • XMLA 读/写终结点：可以使用 XMLA 终结点与有效的 model.bim 文件相结合，创建 或 更改 语义模型。 XMLA 终结点允许将更改部署到特定模型对象，而不是整个模型。 Azure Pipelines 可以使用第三方工具（如表格编辑器命令行接口）来使用 XMLA 终结点部署语义模型。

提示

使用 Fabric 或 Power BI REST API 时，必须先在 Azure 中创建应用注册（此处所述的 Power BI Embedded）。 这需要一个 Microsoft Entra ID 租户和一个组织用户，并且设置相应权限可能是一个复杂的过程。 但是，可以在笔记本中执行 Fabric REST API，而无需创建应用注册。 这简化了解决方案中的 API 的设置和使用，因此无需在使用 API 之前管理凭据或配置任何设置。

若要在不注册应用的情况下使用 Fabric REST API，请将 Fabric 笔记本中的 语义链接 与 sempy 的 FabricRestClientClass 配合使用来调用 API。

与自动测试一起，Azure Pipelines 与 Power BI 的集成有助于实现 持续集成和持续部署（CI/CD）。

使用 Azure Pipelines 时，管道所有者可以自定义触发器、步骤和功能以满足部署需求。 因此，管道的数量和类型因解决方案要求而异。

可以设置三种类型的 Azure Pipelines 来测试、管理和部署 Power BI 解决方案。

  • 验证管道
  • 构建管道
  • 发布管道

注意

发布解决方案中不必包含所有三种类型的管道。 根据工作流和需求，可以设置本文所述的管道的一个或多个变体，以自动执行内容发布。 自定义管道的功能是 Azure Pipelines 优于内置 Fabric 部署管道的优势。

验证管道

在将数据模型发布到开发工作区之前，验证管道将执行数据模型的基本质量检查。 通常，远程存储库分支中的更改会触发管道，通过自动测试来验证这些更改。

自动化测试的示例包括使用 最佳做法分析器（BPA）或针对已发布语义模型运行 DAX 查询来扫描数据模型以查找最佳做法规则冲突。 然后，这些测试的结果将存储在远程存储库中，以用于文档和审核目的。 不应发布验证失败的数据模型。 相反，流程应通知内容创建者有关问题。

构建管道

构建管道 准备要发布到 Power BI 服务的数据模型。 这些管道将序列化的模型元数据合并到发布管道稍后发布的单个文件中。 生成管道还可以更改元数据，例如修改参数值。 生成管道生成部署项目，这些项目由数据模型元数据（用于数据模型）和 Power BI 项目 （.pbip） 文件组成，这些文件可供发布到 Power BI 服务。

发布管道

发布管道发布或部署内容。 发布解决方案通常包括多个发布管道，具体取决于目标环境。

  • 开发发布管道：此第一个管道会自动触发。 生成和验证管道成功后，它将内容发布到开发工作区。
  • 测试和生产发布管道：这些管道不会自动触发。 而是按需触发，或在获得批准时触发。 发布批准后，测试和生产发布管道分别将内容部署到测试或生产工作区。 发布批准可确保内容在准备就绪之前不会自动部署到测试或生产阶段。 这些审批由发布经理提供，他们负责规划和协调内容发布以测试和生产环境。

决定如何在工作区之间推广内容

对开发、测试和生产使用不同的环境时，必须将内容部署到所有三个环境。 可以使用不同的工具和方法在工作区之间推广内容，具体取决于特定的工作流和需求。

以下部分介绍了在工作区之间推广内容时可以采用的方法。

谨慎

避免从本地计算机手动发布内容以测试和生产工作区。 这可能会因为错误而导致故障或中断。 一般来说，应只发布到开发工作区，或者如果使用专用工作区，则发布到专用工作区。

使用 Fabric 部署管道进行部署

使用部署管道可以设置两个或更多阶段（例如开发、测试或生产），并在这些阶段之间部署 Fabric 内容。 管道管理员将单个 Power BI 工作区分配给部署管道中的每个阶段。 如何使用部署管道取决于你决定如何设置和使用工作区。

请考虑在以下情况下使用部署管道：

  • 在 PPU、高级容量或 Fabric 容量许可模式下将内容部署到工作区。
  • 部署管道支持内容项类型和场景。

在以下情况下，请考虑部署管道以外的另一种方法：

  • 你更喜欢使用 Azure Pipelines 将内容从远程存储库中进行部署。
  • 你打算使用 Git 集成将不同阶段与远程存储库的不同分支同步，而不是部署内容。

提示

有关如何使用部署管道在工作区之间提升内容的详细信息，请参阅 自助服务内容发布 和 企业内容发布 使用方案。

有关部署管道的详细信息，请参阅 部署管道：了解部署过程。

使用部署管道的最简单方法是将所有内容发布到单个工作区，并将其提升到单个部署管道中的后续阶段。 下图描述了使用部署管道部署内容的第一种方法。

关系图显示了方法 1，即使用部署管道进行内容部署。接下来将介绍关系图中的项。

总之，内容创建者通常首先将内容发布到管道的初始阶段。 然后，为了将内容提升到后续阶段，管道管理员将触发部署。 部署发生时，部署管道将内容元数据从一个工作区部署到下一个工作区。

在不同工作区中按项类型分隔内容时，将使用单独的部署管道来部署此内容。 可以使用自动绑定将工作区之间的内容链接到多个部署管道。 跨部署管道的自动绑定确保内容始终链接到各阶段的对应项目。 例如，开发阶段中的报表将与其他部署管道的开发阶段中的模型保持链接。 但是，如果你的方案要求你使用不同的模式跨工作区链接内容，也可以避免自动绑定行为。

下图描述了使用多个部署管道部署内容的第二种方法。

关系图显示了方法 2，即使用多个管道进行内容部署。接下来将介绍关系图中的项。

总之，使用多个部署管道部署内容类似于使用单个管道。 一个关键区别在于，可以选择性地使用自动绑定来链接跨多个工作区和部署管道关联的内容。 否则，它与第一种方法相同。

部署管道是一种灵活的简单工具，适合为自助服务和企业方案改进内容生命周期管理。

执行部署的用户需要访问工作区和部署管道。 建议 计划部署管道访问，以便管道管理员可以查看部署历史记录并比较内容。 与多个内容创建者协作时，请考虑限制对最适合监督部署和发布流程的发布经理或技术所有者的管道访问。

此外，请考虑使用 部署规则 为不同阶段的项目设置不同的配置。 例如，你可能希望开发工作区中的语义模型从开发数据库源数据，而生产工作区中的语义模型则从生产数据库源数据。

提示

如果多人有权访问您的部署管道，建议定期查看 和 部署历史记录。 这些评审可帮助你识别未经批准的部署或部署失败。

如果您使用 自动绑定 以跨部署管道连接项目，请务必查看项目传承，以识别由于某人将链接内容发布到错误阶段而导致的自动绑定故障。

可以使用 Power BI REST API手动或编程方式触发部署。 在这两种情况下，你都应该定义一个清晰可靠的过程，说明何时将内容推广到每个阶段，以及如何回滚意外更改。

手动执行部署

可以使用 Fabric 部署管道手动部署内容。 可以选择 部署全部内容 或者 选择项目。 当某些内容准备好进入下一阶段时，选择性部署可能很有用，但某些项目仍在进行开发或验证。 此外，当后期阶段存在内容更改但前期阶段不存在内容更改时，可以执行向后部署。

谨慎

使用部署管道时，我们建议你以单个方向部署内容，例如从开发到测试到生产工作区。 通常，在开发或测试中对这些更改进行适当的验证之前，应避免在后续阶段对内容进行更改。

进行手动部署时，可以比较阶段，以确定“更改评审”窗口中的内容更改。 如果不将 Git 远程存储库用于源代码管理，此方法特别有用。

使用 Power BI REST API 执行部署

可以使用 Power BI REST API 通过部署管道来部署内容。 使用 REST API 的好处是，可以自动部署并将其与 Azure DevOps 中的 Azure Pipelines 等其他工具集成。

使用 Azure Pipelines 进行部署

使用 Azure Pipelines 可以协调所有阶段之间的部署。 使用这种方法，您可以利用 Fabric REST API 来部署和管理内容，采用不同的 Azure 管道，如验证和发布管道。

请考虑在以下情况下使用 Azure Pipelines：

  • 你想要从 Azure DevOps 中集中协调部署。
  • 内容创建者使用 Azure DevOps 进行协作和源代码管理。

在以下情况下，请考虑使用 Azure Pipelines 以外的另一种方法：

  • 内容创建者不熟悉 Azure DevOps 或基于代码的部署。
  • 内容包括没有受支持的定义或源文件格式的项目类型，如仪表板。

使用 Azure Pipelines 部署内容有两种不同的方法。 要么协调部署管道，要么将内容部署到工作区，而无需部署管道。

使用 Azure Pipelines 协调 Fabric 部署管道

在此方法中，发布管道通过部署管道来统筹和管理内容部署，以将内容部署到测试和生产工作区。 内容通过 Fabric 中的开发、测试和生产工作区进行推广。

下图描述了如何从 Azure Pipelines 协调部署管道。

关系图显示了方法 3，这是关于从 Azure Pipelines 协调内容部署。接下来将介绍关系图中的项。

总之，内容创建者将内容发布到部署管道第一阶段的工作区。 然后，发布管理器批准部署，这一批准会触发 Azure Pipeline。 此管道使用 Power BI REST API 在阶段之间提升内容，以便元数据部署到另一个工作区。 此方法的一个优点是，可以通过部署管道协调多个 Fabric 项类型的部署，因为某些项类型是在 Fabric 门户中开发的，因此不能单独由 Azure Pipelines 部署。

通过仅使用 Azure Pipelines 部署内容

还可以使用 Azure Pipelines 将内容从 Azure DevOps 部署到工作区。 此方法不使用部署管道。 相反，它使用发布管道通过 Fabric 或 Power BI REST API 或 XMLA 读/写终结点来部署源文件或元数据文件。 通常，这些文件存储在 Azure Repos Git 存储库中。

下图描述了如何使用 Azure Pipelines 部署内容。

关系图显示了方法 4，即仅使用 Azure Pipelines 来部署内容。接下来将介绍关系图中的项。

总之，内容创建者将内容更改提交并推送到 Azure Repos 中的远程 Git 存储库。 Azure Pipelines 使用此内容进行部署。 发布管理器批准特定部署后，Azure Pipeline 将使用 Power BI REST API（即 .pbix 文件）、Fabric REST API（即项定义）或 XMLA 终结点（即 model.bim 文件）将内容部署到工作区。 每个工作区存在单独的 Azure Pipeline。

仅使用 Power BI REST API 发布 Power BI Desktop 文件时，此方法不需要 Fabric 容量或高级许可。 但是，它确实涉及更多的设置工作和复杂性，因为你必须在 Power BI 外部管理部署。 已将 DevOps 用于 Power BI 外部数据解决方案的开发团队可能熟悉此方法。 使用此方法的开发团队可以在 Azure DevOps 中整合数据解决方案的部署。

使用 Fabric Git 集成进行部署

使用 Git 集成时，可以将不同的分支同步到不同的工作区，而不是显式发布或部署内容。 这样，就可以为开发、测试和生产工作区创建单独的分支。 在此方案中，主分支与生产工作区同步。 然后，通过执行拉取请求在工作区之间部署内容，将开发分支合并到测试分支（部署到测试工作区），或将测试分支合并到主分支（部署到生产工作区）。

下图描述了如何使用 Fabric Git 集成将分支同步到不同的工作区来部署内容。 为简单起见，图表不包含分支或合并内容的详细信息。

关系图显示了方法 5，即使用 Fabric Git 集成进行内容部署。接下来将介绍关系图中的项。

总之，内容创建者将内容更改提交并推送到 Azure Repos 中的远程 Git 存储库。 内容创建者打开拉取请求（PR），请求将其更改合并到特定分支。 根据分支策略，不同的分支连接到不同的工作区。 将更改合并到分支后，内容创建者会将工作区与远程 Git 存储库同步，以查看该工作区中内容的最新更改。

在以下情况下，请考虑使用此方法：

  • 你希望使用分支和合并策略协调工作区之间的部署。
  • 你不打算使用 Azure Pipelines 或 Fabric 部署管道来协调部署以测试和生产。
  • 工作区不包含不受支持的项或方案。
  • 内容没有敏感度标签。

注意

部署内容有多种有效方法。 例如，可以使用本文中讨论的不同方法的组合。

例如，可以使用 Azure Pipeline 将内容部署到开发工作区，这样就可以从持续集成功能中受益，并执行自动化测试（例如使用最佳做法分析器）。 然后，可以使用 Git 集成或 Fabric 部署管道在工作区之间部署内容。

选择最适合需求的方法和团队的工作方式。

决定如何处理部署后活动

部署后，必须处理各种 部署后活动。 其中许多活动可以通过编程方式进行处理，例如，Azure Pipeline 或 Notebook 以及 Power BI 和 Fabric REST API。 例如，可以编程方式设置数据源凭据、管理计划的刷新，并在元数据部署后触发刷新。 但是，某些任务需要手动干预，例如首次设置或更新 Power BI 应用。

确保识别出所有与内容相关的部署后的活动，并决定如何处理它们。

规划内容部署方式后，接下来应考虑如何支持和监视内容。

清单 - 规划如何部署内容时，关键决策和行动包括：

  • 确定可用的部署选项：根据你的许可和内容，你将有不同的选项可用于发布内容或在工作区之间推广它。 确定是否可以使用部署管道、Azure DevOps、Git 集成、Fabric REST API 和 XMLA 读/写终结点。
  • 决定如何发布内容：选择最适合工作流和需求的发布内容的方法。 确保此方法与其他策略保持一致，例如跟踪和管理更改的方式。
  • 决定如何在工作区之间提升内容：选择一种方法，将内容从开发部署到测试工作区，以及从测试工作区部署到生产工作区。 确保此方法与其他策略保持一致，例如发布内容的方式。
  • 规划发布策略：在批准发布或部署之前，确定特定个人是否负责对内容进行最终评审。 确保此人知道这个任务，以及他们应该做些什么来保护部署过程，并确保不会阻碍进度。
  • 规划部署后活动：确保已决定执行诸如更新 Power BI 应用或在元数据部署后刷新数据项等活动的过程。 请考虑使用 Fabric REST API 自动执行此过程。
  • 执行第一次设置部署工具和流程：确保设置适当的访问权限，该权限与设置对内容的访问权限的方式一致。
  • 将内容部署到生产：规划并设置部署后，将内容部署到生产环境。

相关内容

在本系列的下一篇文章中，了解如何在管理内容生命周期过程中支持和监视内容。