Power BI 使用方案：企业内容发布
备注
本文是 Power BI 实现规划系列文章中的一篇。 本系列着重介绍 Microsoft Fabric 中的 Power BI 体验。 有关该系列的介绍，请参阅 Power BI 实施规划。
当内容创建者协作交付对组织很重要的分析解决方案时，他们必须确保及时可靠地向使用者交付内容。 技术团队使用名为 DevOps 的过程来应对这一挑战。 DevOps 允许团队通过采用改进和加速交付的做法来自动化和缩放流程。
注意
应对相同挑战的数据团队也可能练习 DataOps。 DataOps 基于 DevOps 原则，但 DataOps 包含特定于数据管理的其他做法，例如数据质量保证和治理。 我们在本文中提到 DevOps，但请注意，基本原则也适用于 DataOps。
在采用 DevOps 做法发布 Power BI 内容时，内容创建者和使用者将受益于多项优势。 以下几点简要概述了此过程的工作原理。
- 开发内容并将工作提交到远程存储库：内容创建者在自己的计算机上开发其解决方案。 在开发过程中，他们定期提交工作并将其保存到远程存储库。 远程存储库包含最新版本的解决方案，整个开发团队都可以访问它。
- 使用版本控制协作和管理内容更改：其他内容创建者可以通过创建分支对解决方案进行修订。 分支是远程存储库的副本。 这些修订准备就绪并批准后，分支将与最新版本的解决方案合并。 将跟踪解决方案的所有修订。 此过程称为版本控制（或源代码管理）。
- 使用管道部署和升级内容：在自助式内容发布使用方案中，内容使用 Power BI 部署管道通过开发、测试和生产工作区进行升级（或部署）。 Power BI 部署管道可以使用用户界面手动将内容提升到 Power BI Premium 工作区，也可以使用 REST API 以编程方式提升内容。 相比之下，企业内容发布（此使用方案的重点）使用 Azure Pipelines 来提升内容。 Azure Pipelines 是一项 Azure DevOps 服务，使用一系列自定义的编程步骤自动测试、管理和部署内容。 在企业内容发布使用方案中，这些管道也可以称为持续集成和部署（或 CI/CD）管道。 这些管道经常自动集成更改并简化内容发布。
重要
有时本文指的是 Power BI Premium 或其容量订阅 (P SKU)。 请注意，Microsoft 目前正在合并购买选项并停用 Power BI Premium Per Capacity SKU。 新客户和现有客户应考虑改为购买 Fabric 容量订阅 (F SKU)。
有关详细信息，请参阅 Power BI Premium 许可即将进行的重要更新和 Power BI Premium 常见问题解答。
DevOps 支持一种成熟、系统化的内容管理和发布方法。 它使内容创建者能够协作处理解决方案，并确保向使用者快速可靠地交付内容。 遵循 DevOps 做法后，即可从简化的工作流、更少的错误以及内容创建者和内容使用者的改进体验中受益。
请使用 Azure DevOps 为 Power BI 解决方案设置和管理 DevOps 实践。 在企业方案中，可以通过三种不同的方式使用 Azure DevOps 和 Power BI REST API 自动发布内容。
- Power BI REST API 与 Power BI 部署管道：可以将内容导入开发工作区，并使用部署管道通过测试和生产工作区部署内容。 你仍将从 Azure DevOps 控制部署，并使用 Power BI REST API 管理部署管道，而不是单个内容项。 此外，使用 XMLA 终结点通过 Azure DevOps 部署数据模型元数据而不是 Power BI Desktop 文件 (.pbix)。 此元数据允许使用版本控制跟踪对象级更改。 虽然此方法更可靠且更易于维护，但需要高级许可和适度的脚本编写工作，以使用 Power BI REST API 设置内容导入和部署。 如果想要使用部署管道简化内容生命周期管理，并且拥有 Premium 许可证，请使用此方法。 XMLA 终结点和 Power BI 部署管道是高级功能。
- Power BI REST API：还可以使用 Azure DevOps 和仅 Power BI REST API 将内容导入开发、测试和生产工作区。 此方法不需要高级许可，但它涉及大量脚本编写工作和设置，因为部署是在 Power BI 外部管理的。 如果要从 Azure DevOps 集中部署 Power BI 内容，或者没有高级许可证，请使用此方法。 有关前两种方法之间的直观比较，请参阅发布管道方法流程图。
- 具有 Power BI 部署管道的 Power BI 自动化工具：可以使用 Power BI 自动化工具 Azure DevOps 扩展来管理部署管道，而不是使用 Power BI REST API。 此方法是第一个选项的替代方法，其将 Power BI REST API 与 Power BI 部署管道配合使用。 Power BI 自动化工具扩展是一种开放源代码工具。 它可帮助管理和发布 Azure DevOps 中的内容，而无需编写 PowerShell 脚本。 如果想要以最少的脚本编写工作量管理 Azure DevOps 中的部署管道，并且具有高级容量，请使用此方法。
本文重点介绍第一个选项，它使用 Power BI REST API 和 Power BI 部署管道。 它介绍如何使用 Azure DevOps 设置 DevOps 实践。 它还介绍了如何对远程存储库使用 Azure Repos，以及如何使用 Azure Pipelines 自动执行内容测试、集成和交付。 Azure DevOps 并不是设置企业内容发布的唯一方法，但与 Power BI 的简单集成使其成为一个不错的选择。
提示
Microsoft Fabric 使用 Fabric Git 集成为企业内容发布提供其他选项。 通过 Git 集成，可以将 Fabric 工作区链接到 Azure Repos 远程存储库中的分支。 保存到该分支的内容将自动同步到工作区，就像将该内容发布到工作区一样。 相反，内容创建者可以将更改从 Fabric 工作区提交和推送到远程存储库。
Git 集成可以简化协作和内容发布，但它需要更详细地规划如何使用 Fabric 工作区和什么是分支策略。 有关如何设置和使用 Fabric Git 集成的详细信息，请参阅 Git 集成入门或教程：端到端生命周期管理。
方案示意图
下图简要概述了支持企业内容发布的最常见用户操作和 Power BI 组件。 重点是使用 Azure DevOps 通过Power BI 服务中的开发、测试和生产工作区以编程方式大规模管理和发布内容。
提示
如果想要将方案图嵌入演示文稿、文档或博客文章，或者将其打印为墙上海报，建议下载方案图。 由于它是可缩放矢量图形 (SVG) 图像，因此你可以放大或缩小它，而不会造成任何质量损失。
该方案图描绘了以下用户操作、流程和功能。
| 项目 | 描述 |
|---|---|
 |
内容创建者使用 Power BI Desktop 或表格编辑器开发数据模型，并使用 Power BI Desktop 开发报表。 内容创建者在开发期间会将其工作保存到本地存储库。 |
 |
内容创建者可以克隆远程存储库以获取该内容的本地副本。 |
 |
某些数据源（例如驻留在专用组织网络中的数据源）可能需要本地数据网关或 VNet 网关来进行数据刷新。 |
 |
内容创建者使用 Git 客户端（如 Visual Studio Code）在开发期间定期提交更改并将其推送到远程存储库。 在该图中，远程存储库是 Azure Repos。 |
 |
其他内容创建者使用 Azure Repos 通过版本控制跟踪更改。 他们通过将更改提交到单独的分支进行协作。 |
 |
对远程存储库中内容的更改会触发 Azure Pipelines。 验证管道是触发的第一个管道。 验证管道会执行自动测试以在发布内容之前对其进行验证。 |
 |
通过验证管道的内容会触发后续生成管道。 生成管道准备要发布到 Power BI 服务的内容。 到此为止，此过程通常称为持续集成 (CI)。 |
 |
使用发布管道发布和部署内容。 发布管道使用 Power BI REST API 或工作区 XMLA 终结点以编程方式将内容导入 Power BI 服务。 使用发布管道进行部署通常称为持续部署 (CD)。 |
 |
发布经理使用 Azure Pipelines 发布审批来控制测试和生产工作区的部署。 在企业内容发布中，发布经理通常会规划和协调测试和生产环境的内容发布。 他们与内容创建者、利益干系人和用户进行协调和沟通。 |
 |
发布管道将内容发布到开发工作区，或将内容从开发工作区升级到测试工作区，或从测试工作区升级到生产工作区。 |
 |
在具有 Fabric 容量许可证模式的工作区中工作的内容创建者可以使用 Git 集成。 通过 Git 集成，内容创建者可以在开发期间在专用工作区中工作。 内容创建者将远程分支（通常是特定功能分支或 bug 分支）从 Azure Repos 同步到其专用工作区。 内容更改在 Azure Repos 中的远程分支与工作区之间同步。 在此场景中，内容创建者不需要使用 Azure Pipelines 来发布内容。 发布后，内容创建者还可以定期提交和推送工作区中的更改。 准备就绪后，内容创建者可以发出拉取请求 (PR)，将其更改合并到主分支。 |
 |
使用 Git 集成时，开发工作区与主分支同步以获取最新版本的内容。 此内容包括发布经理评审、批准和合并的拉取请求中的所有更改。 |
 |
工作区设置为 Fabric 容量、高级容量、Premium Per User 或 Embedded 许可证模式，以允许使用 Power BI 部署管道和 XMLA 读/写终结点。 |
 |
部署管道管理员为 Power BI 部署管道设置三个阶段：开发、测试和生产。 每个阶段与 Power BI 服务中的一个独立工作区相对应。 为部署管道设置了部署设置和访问权限。 |
 |
开发工作区包含最新版本的内容，包括所有已批准和合并的更改。 批准后，发布管道会将开发内容部署到测试工作区。 |
 |
测试工作区中的评审员对内容执行测试和质量保证。 批准后，发布管道会将测试中的内容部署到生产工作区。 当使用 Git 集成部署管道时，测试工作区不会与任何分支同步。 |
 |
部署管道完成部署后，内容创建者手动执行部署后活动。 活动可能包括为生产工作区设置计划的数据刷新或更新 Power BI 应用。 当使用 Git 集成部署管道时，生产工作区不会与任何分支同步。 |
 |
内容查看者使用生产工作区或 Power BI 应用访问内容。 |
要点
下面是对于企业内容发布方案需要强调的一些要点。
版本控制
跟踪内容生命周期中的更改对于确保向使用者稳定且一致地交付内容非常重要。 在此使用方案中，内容创建者和所有者使用版本控制管理远程存储库中的内容更改。 版本控制是管理对中央存储库中文件或代码的更改的做法。 这种做法可实现更好的协作和版本历史记录的有效管理。 版本控制对内容创建者具有优势，包括回滚或合并更改的功能。
内容创建者通常在表格编辑器中开发数据模型，以支持更好的版本控制。 与在 Power BI Desktop 中开发的数据模型不同，在表格编辑器中开发的数据模型将以用户可读的元数据格式保存。 此格式启用数据模型对象级版本控制。 在与多个人员协作处理同一数据模型时，应使用对象级版本控制。 有关详细信息，请参阅高级数据模型管理使用情况方案。 无法查看在 Power BI Desktop 文件 (.pbix) 中所做的更改，例如报表定义或数据模型。 例如，无法跟踪对报表页的更改，例如所使用的视觉对象、其位置以及字段映射或格式设置。
内容创建者将数据模型元数据文件和 .pbix 文件存储在中心远程存储库中，如 Azure Repos。 这些文件由技术所有者策展。 当内容创建者开发解决方案时，技术所有者负责管理解决方案和查看更改，并将其合并为单个解决方案。 Azure Repos 提供了用于跟踪和管理更改的复杂选项。 此方法不同于自助式内容发布使用方案中所述的方法，其中创建者使用带有版本跟踪的 OneDrive 存储。 维护精心策划、记录良好的存储库至关重要，因为它是所有内容和协作的基础。
下面是帮助你设置远程存储库以进行版本控制的一些关键注意事项。
- 范围：明确定义存储库的范围。 理想情况下，存储库的范围与用于将内容交付给使用者的下游工作区和应用的范围相同。
- 访问：应使用与为部署管道权限和工作区角色设置的类似权限模型来设置对存储库的访问。 内容创建者需要访问存储库。
- 文档：将文本文件添加到存储库，以记录其用途、所有权、访问权限和定义的流程。 例如，文档可以描述应如何暂存和提交更改。
- 工具：若要提交更改并将其推送到远程存储库，内容创建者需要 Visual Studio 或 Visual Studio Code 等 Git 客户端。 Git 是一个分布式版本控制系统，用于跟踪文件中的更改。 若要了解 Git 基础知识，请参阅什么是 Git？。
注意
如果计划提交 Power BI Desktop 文件 (.pbix)，请考虑使用 Git 大型文件存储 (LFS)。 Git LFS 提供了高级选项，用于管理更改不可见的文件（不可区分的文件），例如 .pbix 文件。 例如，可以使用文件锁定来防止在开发期间并发更改 Power BI 报表。 但是，Git LFS 具有自己的客户端和配置。
与 Azure DevOps 协作
随着解决方案的范围扩大和复杂性增加，多个内容创建者和所有者可能需要协作。 内容创建者和所有者使用 Azure DevOps 在一个集中的、有组织的中心进行通信和协作。
若要在 Azure DevOps 中协作和沟通，请使用支持服务。
- Azure Boards：内容所有者使用版块跟踪工作项。 每个工作项都分配给团队中的单个开发人员，它们描述解决方案中的问题、bug 或功能，以及相应的利益干系人。
- Azure Wiki：内容创建者与其团队共享信息，以了解解决方案并为其做出贡献。
- Azure Repos：内容创建者跟踪远程存储库中的更改并将其合并到单个解决方案中。
- Azure Pipelines：管道所有者设置编程逻辑以自动或按需部署解决方案。
协作流程图
下图简要概述并举例说明 Azure DevOps 如何在企业内容发布使用场景中实现协作。 此图表的重点在于使用 Azure DevOps 创建一个结构化和文档化的内容发布过程。
该图表描绘了以下用户操作、流程和功能。
| 项目 | 描述 |
|---|---|
|
内容创建者通过克隆包含最新版本内容的主分支来创建一个生存期短的新分支。 新分支通常称为“功能”分支，因为它用于开发特定功能或修复特定问题。 |
|
内容创建者在开发期间将其更改提交到本地存储库。 |
|
内容创建者将其更改链接到 Azure Boards 中管理的工作项。 工作项描述其分支范围的特定开发、改进或 bug 修复。 |
|
内容创建者定期提交其更改。 准备就绪后，内容创建者将其分支发布到远程存储库。 |
|
为了测试更改，内容创建者将其解决方案部署到独立的工作区以进行开发（此图中未显示）。 内容创建者还可以使用 Fabric Git 集成将功能分支同步到工作区。 |
|
内容创建者和内容所有者在 Azure Wiki 中记录解决方案及其过程，可供整个开发团队使用。 |
|
准备就绪后，内容创建者会开启一个拉取请求，将功能分支合并到主分支中。 |
|
技术所有者负责查看拉取请求和合并更改。 当他们批准拉取请求时，会将功能分支合并到主分支中。 |
|
成功的合并会触发通过使用 Azure Pipeline 将解决方案部署到开发工作区的过程（此图中未显示）。 使用 Fabric Git 集成时，主分支会同步到开发工作区。 |
|
发布经理对解决方案执行最终审查和批准。 此发布批准可防止解决方案在准备就绪之前发布。 在企业内容发布中，发布经理通常会规划和协调将发布到测试和生产工作区的内容。 他们与内容创建者、利益干系人和用户进行协调和沟通。 |
|
当发布经理批准发布时，Azure Pipelines 会自动准备解决方案以供部署。 另外，Azure Pipeline 还可以触发部署管道以提升多个工作区之间的内容。 |
|
用户会测试并验证测试工作区中的内容。 将 Git 集成与 Azure Pipelines 用于部署时，测试工作区不会与任何分支同步。 |
|
在用户接受和验证更改后，发布经理会执行解决方案的最终评审并批准，以便部署到生产工作区。 |
|
用户会查看发布到生产工作区的内容。 将 Git 集成与 Azure Pipelines 用于部署时，生产工作区不会与任何分支同步。 |
详细地说，内容创建者通过使用分支策略实现协作。 分支策略是指内容创建者如何创建、使用和合并分支以有效进行内容更改和加以管理。 各个内容创建者在其本地存储库中独立工作。 准备就绪后，他们将更改合并为远程存储库中的单个解决方案。 内容创建者应将其工作范围限定为分支，方法是将它们链接到工作项，以便进行特定的开发、改进或 bug 修复。 每个内容创建者为其工作范围创建自己的远程存储库分支。 在本地解决方案上完成的工作将提交并推送到远程存储库中的分支版本，并带有提交消息。 提交消息描述在该提交中所做的更改。
若要合并更改，内容创建者将打开拉取请求。 拉取请求是同行审查的提交，可导致将完成的工作合并到单个解决方案中。 合并可能会导致冲突，必须先解决这些冲突，然后才能合并分支。 拉取请求审查对保创建者遵守组织在开发、质量和合规性方面的标准和做法非常重要。
协作建议
建议为内容创建者应如何协作定义结构化流程。 确保确定：
- 工作的范围以及分支的创建、命名和使用方式。
- 作者如何将更改分组并通过提交消息描述它们。
- 谁负责审查和批准拉取请求。
- 如何解决合并冲突。
- 不同分支中所做的更改如何合并到单个分支中。
- 如何测试内容以及部署内容之前由谁执行测试。
- 如何以及何时将更改部署到开发、测试和生产工作区。
- 应如何以及何时回滚解决方案的更改或版本。
重要
DevOps 提供的值与定义其使用的流程之遵守成正比。
成功的协作取决于定义完善的流程。 必须清楚地描述和记录端到端开发工作流。 确保所选的策略和流程与团队中的现有做法保持一致，如果不，则应与管理更改的方式保持一致。 此外，请确保流程清晰，并传达给所有团队成员和利益干系人。 确保刚开始了解流程的团队成员和利益干系人接受了如何采用这些流程的培训，并意识到成功采用 DevOps 的价值。
Power BI REST API
使用 Power BI REST API 开发从 Azure DevOps 导入和部署内容的编程逻辑。 请使用导入操作将 Power BI 文件 (.pbix) 导入到工作区。 使用管道操作通过 Power BI 部署管道将部分内容或全部内容部署到测试或生产工作区。 编程逻辑在 Azure Pipelines 中定义。
建议使用服务主体在管道中调用 Power BI REST API。 服务主体适用于无人参与的自动化活动，它不依赖于用户凭据。 但是，某些项和活动不受 Power BI REST API 支持，或者使用服务主体（如数据流）时不受支持。
使用服务主体时，请务必仔细管理权限。 目标应是遵循最小特权原则。 应为服务主体设置足够的权限，而无需过度预配权限。 使用 Azure Key Vault 或其他安全存储服务主体机密和凭据的服务。
注意
如果你有数据模型保存为可读元数据格式，则无法使用 Power BI REST API 发布该模型。 相反，必须使用 XMLA 终结点发布它。 可以使用第三方工具（例如表格编辑器命令行接口 (CLI)）发布元数据文件。 还可以使用自己的自定义 .NET 开发以编程方式发布元数据文件。 开发自定义解决方案需要付出更多精力，因为必须使用分析管理对象 (AMO) 客户端库的 Microsoft 表格对象模型 (TOM) 扩展。
Azure Pipelines
Azure Pipelines 以编程方式自动执行内容的测试、管理和部署。 管道运行时，管道中的步骤会自动执行。 管道所有者可以自定义其触发器、步骤和功能以满足部署需求。 因此，管道的数量和类型因解决方案要求而异。 例如，Azure Pipeline 可以在部署之前运行自动测试或修改数据模型参数。
可以设置三种类型的 Azure Pipelines 来测试、管理和部署 Power BI 解决方案：
- 验证管道。
- 生成管道。
- 发布管道。
注意
发布解决方案中不需要有这三个管道。 根据工作流和需求，可以设置本文中所述管道的一个或多个变体，以自动发布内容。 这种自定义管道的功能是 Azure Pipelines 相对于内置 Power BI 部署管道的优势。 例如，无需具有验证管道；只能使用生成和发布管道。
验证管道
在数据模型发布到开发工作区之前，验证管道会对数据模型执行基本质量检查。 通常，远程存储库分支中的更改会触发管道，通过自动测试来验证这些更改。
自动测试的示例包括使用最佳做法分析器 (BPA) 扫描数据模型，或针对已发布的语义模型运行 DAX 查询，以查找违反最佳做法规则的情况。 然后，这些测试的结果将存储在远程存储库中，以便进行记录和审核。 不应发布未通过验证的数据模型。 相反，管道应将问题通知给内容创建者。
生成管道
生成管道准备要发布到 Power BI 服务的数据模型。 这些管道将序列化的模型元数据合并为一个文件，该文件稍后由发布管道发布（如发布管道图中所述）。 生成管道还可以对元数据进行其他更改，例如修改参数值。 生成管道生成由数据模型元数据（用于数据模型）和准备好发布到 Power BI 服务的 Power BI 桌面文件 (.pbix) 组成的部署项目。
发布管道
发布管道发布或部署内容。 发布解决方案通常包括多个发布管道，具体取决于目标环境。
- 开发发布管道：第一个管道会自动触发。 生成和验证管道成功后，它会将内容发布到开发工作区。
- 测试和生产发布管道：这些管道不会自动触发。 相反，它们会按需触发或在获得批准时触发。 发布批准后，测试和生产发布管道分别将内容部署到测试或生产工作区。 发布批准可确保内容在准备就绪之前不会自动部署到测试或生产阶段。 这些审批由发布经理提供，他们负责规划和协调面向测试和生产环境的内容发布。
可通过两种不同的方法通过测试和发布管道发布内容。 他们要么使用 Power BI 部署管道来提升内容，要么从 Azure DevOps 将内容发布到 Power BI 服务。
下图描述了第一种方法。 在此方法中，发布管道使用 Power BI 部署管道来协调到测试和生产工作区的内容部署。 内容通过 Power BI 中的开发、测试和生产工作区进行提升。 虽然此方法更可靠且更易于维护，但需要高级许可。
此图描述了第一种方法的以下用户操作、流程和功能。
| 项目 | 描述 |
|---|---|
|
在第一种方法中，发布管道使用 XMLA 终结点和 Power BI REST API 以及 Power BI 部署管道发布内容。 内容通过开发、测试和生产工作区进行发布和提升。 Power BI 部署管道和 XMLA 读/写终结点是高级功能。 |
|
成功合并分支或完成上游管道会触发生成管道。 然后，生成管道准备要发布的内容，并触发开发发布管道。 |
|
开发发布管道使用 XMLA 终结点（用于数据模型元数据）或 Power BI REST API（用于 Power BI Desktop 文件，其可能包含数据模型和报表）将内容发布到开发工作区。 开发管道使用表格编辑器命令行接口 (CLI) 通过 XMLA 终结点部署数据模型元数据。 |
|
发布批准或按需触发器激活测试发布管道。 |
|
测试发布管道使用 Power BI REST API 部署操作来部署内容，其运行 Power BI 部署管道。 |
|
Power BI 部署管道将内容从开发工作区提升到测试工作区。 部署后，发布管道使用 Power BI REST API 执行部署后活动（图中未显示）。 |
|
发布批准或按需触发器激活生产发布管道。 |
|
生产发布管道使用 Power BI REST API 部署操作来部署内容，其运行 Power BI 部署管道。 |
|
Power BI 部署管道将内容从测试工作区提升到生产工作区。 部署后，发布管道使用 Power BI REST API 执行部署后活动（图中未显示）。 |
下图描述了第二种方法。 此方法不使用部署管道。 相反，它使用发布管道将内容发布到 Azure DevOps 中的测试和生产工作区。 值得注意的是，当你仅使用 Power BI REST API 发布 Power BI Desktop 文件时，第二种方法不需要高级许可。 它确实涉及更多的设置工作量和复杂性，因为你必须在 Power BI 外部管理部署。 已在 Power BI 外部对数据解决方案使用 DevOps 的开发团队可能更熟悉此方法。 使用此方法的开发团队可以在 Azure DevOps 中合并数据解决方案的部署。
此图描述了第二种方法的以下用户操作、流程和功能。
| 项目 | 描述 |
|---|---|
|
在第二种方法中，发布管道仅使用 XMLA 终结点和 Power BI REST API 发布内容。 内容将发布到开发、测试和生产工作区。 |
|
成功合并分支或完成上游管道会触发生成管道。 然后，生成管道准备要发布的内容，并触发开发发布管道。 |
|
开发发布管道使用 XMLA 终结点（用于数据模型元数据）或 Power BI REST API（用于 Power BI Desktop 文件，其可能包含数据模型和报表）将内容发布到开发工作区。 开发管道使用表格编辑器命令行接口 (CLI) 通过 XMLA 终结点部署数据模型元数据。 |
|
发布批准或按需触发器激活测试发布管道。 |
|
开发发布管道使用 XMLA 终结点（用于数据模型元数据）或 Power BI REST API（用于 Power BI Desktop 文件，其可能包含数据模型和报表）将内容发布到测试工作区。 开发管道使用表格编辑器命令行接口 (CLI) 通过 XMLA 终结点部署数据模型元数据。 部署后，发布管道使用 Power BI REST API 执行部署后活动（图中未显示）。 |
|
发布批准或按需触发器激活生产发布管道。 |
|
开发发布管道使用 XMLA 终结点（用于数据模型元数据）或 Power BI REST API（用于 Power BI Desktop 文件，其可能包含数据模型和报表）将内容发布到生产工作区。 开发管道使用表格编辑器命令行接口 (CLI) 通过 XMLA 终结点部署数据模型元数据。 部署后，发布管道使用 Power BI REST API 执行部署后活动（图中未显示）。 |
发布管道应管理部署后活动。 这些活动可能包括为测试和生产工作区设置语义模型凭据或更新 Power BI 应用。 建议设置通知，以通知相关人员有关部署活动的信息。
提示
使用存储库进行版本控制允许内容创建者创建回滚过程。 回滚过程可以通过还原以前的版本来反转上一个部署。 请考虑创建一组单独的 Azure Pipelines，可以触发这些 Azure Pipelines 来回滚生产更改。 请仔细考虑启动回滚需要哪些流程和审批。 确保记录这些过程。
Power BI 部署管道
Power BI 部署管道由三个阶段组成：开发、测试和生产。 将单个 Power BI 工作区分配给部署管道中的每个阶段。 发生部署时，部署管道会将 Power BI 项从一个工作区提升到另一个工作区。
Azure Pipelines 发布管道使用 Power BI REST API 通过 Power BI 部署管道部署内容。 执行部署的用户需要有权访问工作区和部署管道。 建议规划部署管道访问，以便管道用户可以查看部署历史记录和比较内容。
提示
将数据工作区与报表工作区分开时，请考虑使用 Azure Pipelines 通过多个 Power BI 部署管道协调内容发布。 首先部署语义模型，然后刷新语义模型。 最后，部署报表。 此方法可帮助你简化部署。
高级许可
Power BI 部署管道和 XMLA 读/写终结点是高级功能。 这些功能具有 Power BI Premium 容量和 Power BI Premium Per User (PPU)。
PPU 是为开发和测试工作区管理企业内容发布的一种经济高效的方式，而开发和测试工作区通常用户很少。 此方法具有将开发和测试工作负载与生产工作负荷隔离的额外优势。
注意
仍可以在没有高级许可证的情况下设置企业内容发布，如发布管道部分中的第二种方法所述。 第二种方法是使用 Azure Pipelines 管理 Power BI Desktop 文件到开发、测试和生产工作区的部署。 但是，无法使用 XMLA 终结点部署模型元数据，因为无法使用 Power BI REST API 发布元数据格式语义模型。 此外，如果没有高级许可证，则无法通过具有部署管道的环境来提升内容。
网关设置
通常，在访问驻留在专用组织网络或虚拟网络中的数据源时需要一个数据网关。 网关的两个作用是刷新导入的数据，以及查看查询实时连接或 DirectQuery 语义模型的报表（方案图中未描绘）。
使用多个环境时，常见的做法是设置与不同源系统的开发、测试和生产连接。 在这种情况下，请使用数据源规则和参数规则来管理在不同的环境中各不相同的值。 可以使用 Azure Pipelines 通过 Power BI REST API 的网关操作来管理网关。
注意
强烈建议使用标准模式的集中式数据网关，而不要使用个人模式的网关。 在标准模式下，数据网关支持实时连接和 DirectQuery 操作（此外还支持计划的数据刷新操作）。
系统监督
活动日志记录 Power BI 服务中发生的事件。 Power BI 管理员可以使用活动日志来审核部署活动。
可以使用 Power BI 元数据扫描 API 创建租户清单。 API 结果有助于验证哪些项已部署到每个工作区、检查世系以及验证安全设置。
Azure DevOps 中还有一个审核日志，该日志位于 Power BI 服务之外。 Azure DevOps 管理员可以使用审核日志来查看远程存储库和管道中的活动。
相关内容
有关可帮助你做出 Power BI 实施决策的其他有用方案，请参阅 Power BI 使用方案一文。