Power BI 实现规划：开发内容和管理更改
注意
本文是 Power BI 实现规划系列文章中的一篇。 本系列着重介绍 Microsoft Fabric 中的 Power BI 体验。 有关该系列的介绍，请参阅 Power BI 实施规划。
本文可帮助你在管理内容生命周期过程中开发内容和管理更改。 主要面向以下对象：
- 卓越中心 (COE) 和 BI 团队：负责在组织中监督 Power BI 的团队。 这些团队包括决定如何管理 Power BI 内容的生命周期的决策者。 这些团队可能还包括发布经理、处理内容发布生命周期的角色，或者创建和管理有效使用和支持生命周期管理所需的组件工程师。
- 内容创建者和内容所有者：创建内容的用户，他们希望将内容发布到 Fabric 门户以与他人共享。 这些人员负责管理其创建的 Power BI 内容的生命周期。
生命周期管理是用于处理内容创建到最终停用的过程和做法。 在生命周期管理的第一个阶段，你规划和设计内容，包括解决方案规划，并做出影响生命周期管理方法的关键决策。 第二个阶段是开发内容和管理更改。
在内容的生命周期内管理内容更改，对于确保内容创建者之间的有效协作以及稳定而一致地向消费者交付内容非常重要。
下图描绘了 Power BI 内容的生命周期，其中突出显示了开发内容和管理更改的第二阶段。
注意
有关内容生命周期管理的概述，请参阅本系列的第一篇文章。
提示
本文重点介绍关键决策和注意事项，帮助你在整个生命周期内开发内容和管理更改。 有关如何开发内容和管理更改的更多指南，请参阅：
- 什么是 Microsoft Fabric 中的生命周期管理？：本文提供有关 Fabric Git 集成和部署管道的技术简介和教程。
- 生命周期管理最佳做法：本文包含有关使用 Fabric 和 Power BI 的生命周期管理功能开发内容和管理更改的实用提示和指南。
- Power BI Desktop OneDrive 和 SharePoint 集成：本文概述了使用 .pbix 文件进行版本控制时，将文件保存到 OneDrive for Work and School 或 SharePoint 的选项和使用存储方法。
- Azure Repos 中的 Git 入门：本系列文章包含有关在 Azure Repos 中使用 Git 存储库执行源代码管理的实用提示、教程和指南。
内容创建者和所有者应使用版本控制来管理内容更改。 版本控制是管理对中央存储库中文件或代码的更改的做法。 这种做法可促进更有效的协作和内容管理。
版本控制的其他优势包括：
- 合并来自多个内容创建者的更改，并处理合并冲突。
- 确定哪些内容已更改，以及做出了什么更改。
- 将内容更改链接到特定工作项。
- 使用版本历史记录将更改分组为不同版本。
- 回滚更改或整个内容版本。
提示
建议尽可能对创建的所有内容使用版本控制。 使用版本控制对内容创建者和使用者都有显著的好处，可降低因文件丢失或无法回滚更改而中断的风险。
设置版本控制的第一步是决定如何开发内容。
决定如何开发内容
根据创作内容的方式，对如何管理内容做出不同的决策。 例如，对于 Power BI 报表和语义模型，与 Power BI Desktop 项目 (.pbip) 格式相比，Power BI Desktop (.pbix) 文件的版本控制选项更少。 这是因为 .pbix 文件是二进制格式，而 .pbip 格式包含基于文本的人类可读内容和元数据。 使用人工可读的内容和元数据，可以使用源代码管理更轻松地跟踪模型和报告更改。 源代码管理是在查看时，管理内容中对其代码和元数据的更改。
提示
使用 Power BI Desktop 开发语义模型和报表时，建议使用 .pbip 文件而不是 .pbix 文件。 使用 XMLA 工具开发语义模型时，建议使用表格模型定义语言 (TMDL) 格式，而不是 .bim 文件。
.pbip 和 TMDL 格式支持更轻松地跟踪和合并对象级更改。 这意味着可以查看和管理对单个对象的更改，例如 DAX 度量值或表。
Power BI Desktop
可以使用 Power BI Desktop 创建语义模型或报表，然后将其另存为 .pbix 或 .pbip 文件。 使用 Power BI Desktop 创建内容时，还可以使用其他自定义内容文件。使用 Power BI Desktop 创建内容时，应做出的一些关键决定包括：
- 要使用的文件格式：可以将内容另存为 .pbix 或 .pbip 文件。 例如，Git 集成要求使用 .pbip 文件，自助服务创建者可能会发现 .pbix 文件在 Teams、SharePoint 或 OneDrive 中更易于管理和维护。
- 如何管理自定义内容：可以将主题、自定义视觉对象或图像添加到 Power BI Desktop 文件，这可能需要对生命周期管理有不同的考量。 例如，当内容创建者创建自己的自定义视觉对象时，它们应在单独的文件中保存和管理视觉对象定义。
- 如何管理预览功能：可以选择在 Power BI Desktop 中预览功能或设置，这会更改内容以及使用它的方式。 例如，可以采取其他步骤来验证使用预览功能的内容。
Web 创作
某些内容（如数据流、仪表板和记分卡）只能在 Fabric 门户中创建。 还可以在 Fabric 门户中或使用本地工具创建或修改某些内容，例如语义模型、报表和分页报表。 使用 Web 创作创建内容时，应做出的一些关键决定包括：
- 如何管理更改：可以使用 Web 创作对许多项类型进行更改，但这些更改可能会立即保存，覆盖以前的版本。 例如，如果你正在与他人协作，你可能希望避免在共享的项上进行 Web 创作，而是在自己的副本上操作。
- 如何检索内容备份：可以使用 Web 创作创建报表或语义模型等内容，但这些项无法下载到本地 .pbix 文件。 例如，可以通过检索和存储内容元数据来选择备份此内容。
提示
开发数据流和记分卡时，建议检索项定义来管理更改并存储备份。 可以使用 Fabric REST API 自动执行数据流和记分卡检索。 具体而言，可以分别使用获取数据流和获取记分卡终结点。
注意
某些内容（如仪表板）无法检索定义。 对于此内容，你无法轻松地跟踪更改或检索备份。
其他工具
可以使用其他工具创建或管理某些类型的内容。 这些工具可以提供额外的优势，更好地适应工作流，或者是管理特定功能或内容类型时所需。 可以使用其他 Microsoft 工具或第三方工具来创建和管理内容。 可用于创建或管理内容的其他工具如下所示。
- Visual Studio 或 Visual Studio Code：开发人员创建和管理语义模型或 Fabric 笔记本的集成开发环境。 通过 visual Studio 和 Visual Studio Code，开发人员还可以通过将本地更改提交和推送到远程存储库来执行源代码管理 (SCM)。
- 表格编辑器：用于开发和管理语义模型的第三方工具。
- Excel：一种与语义模型配合使用的数据透视表和实时连接表的客户端工具。
- Power BI Report Builder：用于创建分页报表 (.rdl) 文件的桌面应用程序。
使用其他工具创建内容时，应做出的一些关键决定包括：
- 如何管理许可证：其他工具可能需要应进行管理的额外许可证。
- 如何发布内容：其他工具可能需要执行其他步骤来发布内容，例如使用 XMLA 终结点或 Power BI REST API。
确定如何创建内容后，接下来需要在开发内容时选择发布和测试内容的位置。
决定如何设置和使用工作区
开发内容时，应使用多个工作区（或阶段）将组织使用的生产内容与开发或验证的内容分开。 为内容使用单独的工作区有几个优点：
- 可以开发和测试内容，而不会影响当前使用的内容。 这可以避免可能对制作的内容造成意外干扰的更改。
- 可以使用单独的资源来开发和测试内容，例如使用单独的数据网关或 Fabric 容量。 这可以避免用于开发和测试的资源中断生产工作负载，以免导致数据刷新或报告速度缓慢。
- 可以通过为每个阶段创建一个更结构化的过程来开发、测试和发布内容。 这有助于提高工作效率。
在 Fabric 和 Power BI 中，建议使用单独的 Fabric 工作区，如租户级别和工作区级别规划文章中所述。
重要
使用单独的环境是确保内容生命周期管理方法成功的重要步骤。
可通过多种方式使用 Fabric 工作区来分隔环境。 通常，除了本地环境外，还可以使用两个或多个工作区来管理其生命周期内的内容。
在规划如何在内容整个生命周期内使用单独的工作区时思考以下问题：
- 你需要多少个工作区？
- 是否会按项类型分隔工作区？
- 谁将有权访问每个工作区？
- 工作区是否属于 Fabric 部署管道，或者是否会使用其他方法（例如使用 Azure Pipelines）来协调部署？
- 你会如何管理跨工作区发布？ 例如，是否需要确保报表的测试工作区中的报表连接到数据项单独测试工作区中的语义模型？
- 是否需要对生产工作区中的项使用单独的支持资源，例如单独的本地数据网关群集？
以下部分简要概述了可以采用的不同工作区来简化生命周期管理。
注意
以下部分重点介绍如何设置和使用单独的工作区。 可以使用以下四种方法之一将内容部署到这些工作区：
- 从 Power BI Desktop 发布。
- 使用 Fabric 部署管道从另一个工作区部署内容。
- 使用 Git 集成从远程 Git 存储库同步内容。
- 使用构造 REST API、Power BI REST API 或 XMLA 终结点以编程方式部署内容。
有关这些部署内容方法的详细信息，请参阅本系列后面的第 4 阶段：部署内容。
测试和生产工作区
当你提供对组织来说不重要的简单内容时，两个工作区通常就足够了。 在此方案中，内容创建者通常对同一项进行有限的协作，并在本地开发内容。
下图描绘了一个简要示例，说明如何仅对测试和生产工作区使用单独的环境。
此图描述了在此方法中分隔工作区的以下过程和组件。
| 项目 | 描述 |
|---|---|
 |
内容创建者在本地环境中开发内容。 |
 |
准备就绪后，内容创建者会将内容发布到测试工作区。 内容创建者可以开发只能通过 Web 创作生成的内容，并在测试工作区中执行内容验证。 |
 |
准备就绪后，内容创建者会将内容部署到生产工作区。 在生产工作区中，内容创建者通过发布 Power BI 应用或从工作区共享内容来分发内容。 |
注意
可通过多种不同的方式设置和使用单独的工作区，并在这些工作区之间部署内容。 但建议不要执行本地开发后再将内容直接发布到生产工作区。 这可能会导致可预防的中断和错误。
开发、测试和生产工作区
在交付业务关键型内容时，通常使用三个或以上单独的工作区。 在此方案中，内容创建者通常会在包含最新版解决方案的其他开发工作区中进行协作。
下图描述了如何将单独的环境与开发、测试和生产工作区配合使用的简要示例。
此图描述了在此方法中分隔工作区的以下过程和组件。
| 项目 | 描述 |
|---|---|
|
内容创建者在本地环境中开发内容。 |
|
准备就绪后，内容创建者会将内容发布到开发工作区。 在开发工作区中，内容创建者可以开发只能通过 Web 创作生成的内容。 内容创建者还可以验证开发工作区中的内容。 |
|
准备就绪后，内容创建者会将内容部署到测试工作区。 在测试工作区中，用户验证工作区或应用中的内容。 |
 |
准备就绪后，内容创建者会将内容部署到生产工作区。 在生产工作区中，内容创建者通过发布 Power BI 应用或从工作区共享内容来分发内容。 |
注意
可以将多达 10 个不同的环境用于部署管道。 例如，你可能希望测试和生产之间具有专门用于特殊类型验证（如性能测试）的预生产环境。
集成了 Git 的专用工作区
在交付业务关键型内容时，每个开发人员还可以使用自己的开发专用工作区。 在此方案中，专用工作区允许内容创建者在 Fabric 门户中测试内容，或使用计划刷新等功能，而不会给开发团队中的其他人造成中断的风险。 内容创建者还可以在此处开发 Fabric 门户中的内容，例如数据流。 使用 Git 集成和 Azure DevOps 管理内容更改时，专用工作区是一个不错的选择。
注意
Azure DevOps 是一套与 Power BI 和 Fabric 集成的服务，可帮助规划和协调内容生命周期管理。 以这种方式使用 Azure DevOps 时，通常会利用以下服务：
- Azure Repos：允许创建和使用远程 Git 存储库，这是用于跟踪和管理内容更改的远程存储位置。
- Azure Pipelines：允许创建和使用一组自动化任务来处理、测试远程存储库中的内容并将该内容部署到工作区。
- Azure Test Plans：允许设计测试来验证解决方案，并使用 Azure Pipelines 一起自动执行质量控制。
- Azure Boards：允许使用板将任务和计划作为工作项进行跟踪，以及链接或引用其他 Azure DevOps 服务的工作项。
- Azure Wiki：允许与团队共享信息，以了解内容并为内容做出贡献。
下图描述了如何在 Git 集成中使用专用工作区来使用单独环境的简要示例。
注意
示意图描述了在将更改合并到主分支之前，单独的开发人员分别处理解决方案的单独分支（分支一和分支二）。 这是 Git 分支策略的简化描述，演示开发人员如何将更改与远程 Git 存储库集成，并从 Fabric 中的 Git 集成中获益。
此图描述了在此方法中分隔工作区的以下过程和组件。
| 项目 | 描述 |
|---|---|
|
每个内容创建者都在自己的本地环境中开发内容。 |
|
准备就绪后，内容创建者提交更改并将其推送到远程存储库，例如 Azure Repos Git 存储库。 |
|
在远程 Git 存储库中，内容创建者通过使用源代码控制来跟踪和管理内容更改，并通过分支和合并内容来推动协作。 |
|
内容创建者将远程存储库的分支与专用工作区同步。 同步后，创建者提交并推送到分支的最新更改在该专用工作区中可见。 不同的内容创建者在进行更改时，在其各自的独立分支上操作。 |
 |
在专用工作区中，内容创建者可以使用 Web 创作来开发内容，并验证自己的更改。 当内容创建者从工作区提交和推送这些更改时，Web 创作对内容所做的更改可以与 Git 存储库中的分支同步。 不同的内容创建者在各自的独立专用工作区中工作。 |
 |
准备就绪后，内容创建者会执行拉取请求，将其更改合并到解决方案的主分支中。 |
 |
合并更改后，主分支会与开发工作区同步。 |
 |
在开发工作区中，内容创建者可以开发 Fabric Git 集成不支持的内容，例如仪表板。 内容创建者还可以验证包含所有最新更改的集成解决方案。 |
 |
准备就绪后，内容创建者会将内容部署到测试工作区。 在测试工作区中，用户对内容执行用户验收测试。 |
 |
准备就绪后，内容创建者会将内容部署到生产工作区。 在生产工作区中，内容创建者通过发布 Power BI 应用或从工作区共享内容来分发内容。 |
支持工作区的资源
使用单独的环境时，还应考虑这将如何影响在这些环境中使用的各种支持资源。 对于这些支持资源，请考虑是否需要将它们分成相同数量的阶段，或者如何协调它们在这些环境中的使用。
- 网关：考虑对生产工作负载使用单独的本地数据网关群集和 VNet 网关。 这不仅有助于防止中断，还有助于确保在需要更新这些网关时的正常运行时间。
- 应用：考虑为测试和生产工作区创建单独的应用。 不能在阶段之间部署或复制应用。 测试工作区中的应用旨在帮助你在将更改部署到生产工作区之前测试内容和应用体验。 生产工作区中的应用旨在向结构化体验中的最终用户提供内容。
- Azure DevOps：如果打算使用 Azure DevOps 协作和协调源代码管理和部署，请考虑如何使用分支和 Azure Pipelines 在这些环境之间部署内容。 有关使用 Azure Pipelines 部署内容的详细信息，请参阅第 4 阶段：部署内容。
确定如何设置和使用工作区后，下一步是决定如何执行版本控制来跟踪和管理内容更改。
决定如何使用版本控制
在 Power BI 中，可以使用 SharePoint/OneDrive 或远程 Git 存储库（例如 Azure Repos，这是 Azure DevOps 的一个组件）来执行版本控制。 在这两种方法中，将本地内容文件添加到远程存储位置，以帮助跟踪和管理更改。 建议仅将 SharePoint 或 OneDrive 用于更小、更简单的项目，因为它缺少支持更大或更复杂的方案的功能和稳定性。
下面是帮助你设置远程存储库以进行版本控制的一些关键注意事项。
- 警报：应在其他人添加、删除或修改关键文件时设置警报。
- 范围：明确定义远程存储位置的范围。 理想情况下，远程存储位置的范围与用于将内容传送给使用者的下游工作区和应用的范围相同。
- 访问：应像为部署管道权限设置和工作区角色设置访问权限一样，使用类似的权限模型来设置对远程存储位置的访问权限。 内容创建者需要访问远程存储位置。
- 文档：将文本文件添加到远程存储位置，以描述远程存储位置及其用途、所有权、访问和定义的进程。
以下各节介绍每个方法和关键注意事项，以便确定应使用哪种方法。
使用 SharePoint 或 OneDrive for Work and School 进行版本控制
SharePoint 具有文件的内置版本控制。 内容创建者可以在本地开发语义模型或报表，其更改将同步到 SharePoint 或 OneDrive for Work and School 文档库。
提示
仅在更简单、较小的方案中使用 SharePoint 或 OneDrive 进行版本控制，例如自助服务内容发布。 对于较大或较复杂的方案，应考虑使用远程 Git 存储库执行源代码管理。
下图概述了如何使用 SharePoint 或 OneDrive 执行版本控制。
此图描述了以下过程和组件。
| 项目 | 描述 |
|---|---|
|
内容创建者在本地环境中开发语义模型和报表，并将这些模型和报表另存为 .pbix 文件。 |
|
准备就绪后，内容创建者保存其更改，这些更改会同步到远程 SharePoint 或 OneDrive for Work and School 库。 |
|
在远程库中，内容创建者跟踪文件级更改，以辅助版本控制。 |
|
内容创建者可以将已发布的语义模型或报表链接到 .pbix 文件，以方便 OneDrive 刷新。 OneDrive 刷新每小时自动发布内容更改。 |
|
在 Fabric 工作区中，内容创建者在 OneDrive 刷新完成后会看到对 Power BI 内容的更改。 |
重要
只能使用包含语义模型或报表的 SharePoint 或 OneDrive for Power BI Desktop 文件执行版本控制。 对于其他 Power BI 项类型（如数据流）或 Fabric 项类型（如笔记本），无法使用 SharePoint 或 OneDrive 轻松地执行版本控制。 对于这些其他项类型，应使用远程 Git 存储库（如 Azure Repos）执行版本控制。
总而言之，内容创建者可以将已发布的语义模型或报表链接到存储在 SharePoint 或 OneDrive for Work and School 库中的 .pbix 文件。 使用此方法时，内容创建者不再需要发布语义模型便可查看更改。 而更改将在每小时自动 OneDrive 刷新后显示。 虽然方便，但此方法也有一些注意事项，并且无法轻易逆转。
SharePoint 或 OneDrive 的版本控制虽然易于设置和管理，但限制较多。 例如，无法查看内容中的更改，也无法比较版本。 此外，无法设置较复杂的流程来管理这些更改（如分支或拉取请求，如本文后面所述）。
请考虑使用 SharePoint 或 OneDrive 跟踪和管理以下情况下的更改：
- 内容仅包含保存为 .pbix 文件的语义模型或报表。
- 自助服务用户创建和管理内容。
- 内容创建者使用 Microsoft Teams 进行协作。
- 内容创建者不熟悉 Git 和源代码管理。
- 内容创建者管理复杂性和协作有限的单个项。
- .pbix 文件应用了敏感度标签，用于加密其内容。
避免在以下情况中使用 SharePoint 或 OneDrive 来跟踪和管理更改：
- 内容由语义模型和报表以外的项类型组成。
- 内容很复杂或范围很大。
- 内容创建者需要同时协作处理同一个项。
以下部分介绍将 SharePoint 或 OneDrive 与 Power BI 结合使用来有效地使用版本控制的其他注意事项。
Microsoft Teams 集成
如果内容创建者将其用于协作，则可以使用 Microsoft Teams 中的文档库。 文档库是 SharePoint 网站，使用文档库（而不是单独的 SharePoint 网站或 OneDrive 文件夹）可确保内容、文件和协作的集中化。
签入和签出代码
应签出你要使用文件，以避免可能发生的更改冲突。 更改完成后，使用描述更改的注释签入文件。 使用 SharePoint 或 OneDrive for Work and School 进行版本控制时，签入和签出文件有助于改进内容创建者之间的协作。 如果使用多个内容创建者签入和签出文件，则可以修改 SharePoint 网站库以查看上次更新和上次签入的注释。
版本历史记录
确保将内容备份到单独的位置，以防 SharePoint 网站文档库发生意外中断。 还应设置 SharePoint 网站中保留的版本数的限制，并删除旧版本。 这可确保版本历史记录保持有意义，并且不会占用太多空间。
对于更复杂的版本控制，可以将文件存储在远程存储库（如 Azure Repos）中，并使用源代码管理管理更改。
使用远程 Git 存储库进行源代码管理
远程 Git 存储库有助于文件的源代码管理，可让内容创建者使用更多选项来跟踪和管理更改。 简言之，内容创建者可以在本地或 Power BI 服务中开发内容，然后将这些更改提交并推送到远程 Git 存储库，例如 Azure Repos
注意
还可以在不使用 Git 集成的情况下对内容执行源代码管理。 在这种情况下，你仍可跟踪和管理远程 Git 存储库中的内容更改，但使用 REST API 或 XMLA 读/写终结点部署内容。 有关部署内容的方法的详细信息，请参阅第 4 阶段：部署内容。
下图简要概述了如何执行源代码管理
此图描述了以下过程和组件。
| 项目 | 描述 |
|---|---|
|
内容创建者在本地环境中开发语义模型和报表，并将这些模型和报表另存为 .pbip 文件。 内容创建者还可以开发语义模型并保存模型元数据。 |
|
准备就绪后，内容创建者保存其更改，这些更改会定期提交并推送到远程 Git 存储库。 |
|
在远程 Git 存储库中，内容创建者跟踪对象级更改，以辅助版本控制。 内容创建者还可以创建分支来处理内容，并使用拉取请求将其更改合并到单个分支。 |
|
内容创建者可以使用 Git 集成从远程存储库同步内容。 它们还可以使用其他方法（例如 Azure Pipelines）和 REST API 来部署内容。 |
|
在 Fabric 工作区中，内容创建者在同步或部署完成后会看到对 Power BI 内容的更改。 内容创建者可以在工作区中创作数据流或笔记本等内容。 如果使用 Git 集成，内容创建者会将此工作区链接到远程存储库的特定分支。 |
|
内容创建者可以使用 Git 集成将更改从工作区提交和推送到远程存储库。 这些更改可以导入工作区中创作的受支持内容的项定义，例如数据流和笔记本。 |
总之，内容创建者将 .pbip 文件、元数据文件和文档存储在中心 Azure Repos 远程存储库中。 这些文件由技术所有者策展。 当内容创建者开发解决方案时，技术所有者负责管理解决方案和查看更改，并将其合并为单个解决方案。 与 SharePoint 和 OneDrive 相比，Azure Repos 提供了更复杂的选项来跟踪和管理更改。 维护精心策划、记录良好的存储库至关重要，因为它是所有内容和协作的基础。
在以下情况下，请考虑使用源代码管理来跟踪和管理更改：
- 集中或分散的团队创建和管理内容。
- 内容创建者使用 Azure DevOps 进行协作。
- 内容创建者熟悉 Git、源代码管理或 DataOps 原则。
- 内容创建者管理复杂或重要的内容，或者期望内容在复杂性和重要性方面扩展和增长。
下面是一些先决条件和注意事项，可帮助你有效地将源代码管理与 Azure DevOps 配合使用。
- Git：若要提交更改并将其推送到远程存储库，内容创建者需要下载并安装 Git。 Git 是一个分布式版本控制系统，用于跟踪文件中的更改。 若要了解 Git 基础知识，请参阅什么是 Git？。
- 工具：若要使用 Git，内容创建者需要对 SCM 使用命令行接口 (CLI) 或图形用户界面 (GUI) 客户端，例如 Visual Studio 或 Visual Studio Code。
- 许可证和权限：若要创建和使用 Azure Repos Git 存储库，内容创建者必须具有以下权限：
- Fabric Git 集成：若要将远程存储库中的内容与 Microsoft Fabric 工作区同步，内容创建者需使用 Fabric Git 集成。 这一点对于跟踪和管理在 Fabric 门户中创建的内容（如数据流）更改非常重要。
提示
为便于通过本地开发进行源代码管理，我们建议使用 Visual Studio Code 等客户端应用程序。 使用 Power BI Desktop 开发内容，然后可以通过暂存、提交和推送对远程存储库的更改，使用 Visual Studio Code 对该内容执行源代码管理。
警告
Fabric Git 集成对支持的项和情况有一些限制。 确保首先验证 Fabric Git 集成是否最适合你的具体情况，或者是否应采用不同的方法来实现源代码管理。
此外，Fabric Git 集成不支持敏感度标签，导出具有敏感度标签的项可能被禁用。 如果内容具有敏感度标签，则应规划如何实现版本控制，同时仍遵循数据丢失防护策略。
将源代码管理与 Azure Repos 配合使用的主要好处是内容创建者之间协作更好，并且有关内容更改和部署的自定义和监督更多。
下图简要概述 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 用于部署时，生产工作区不会与任何分支同步。 |
以下部分介绍了使用 Azure DevOps 和 Power BI 有效使用源代码管理的其他注意事项。
重要
在管理 Power BI 内容的生命周期时，有效地使用分支、提交、拉取请求和合并对于获取源代码管理的益处至关重要。
使用分支
内容创建者通过使用分支策略实现协作。 分支策略允许单个内容创建者在本地存储库中独立工作。 准备就绪后，他们将更改合并为远程存储库中的单个解决方案。 内容创建者应将其工作范围限定为分支，方法是将它们链接到工作项，以便进行特定的开发、改进或 bug 修复。 每个内容创建者为其工作范围创建自己的远程存储库分支。 在本地解决方案上完成的工作将提交并推送到远程存储库中的分支版本，并带有描述性提交消息。 提交消息描述在该提交中所做的更改。
使用分支策略管理 Fabric 内容时，请考虑以下因素。
- 哪些分支内容创建者应克隆自己的工作。 例如，如果这些分支是主分支（称为基于中继的开发）的克隆，或者它们是其他分支（例如内容特定计划版本的发布分支）。
- 是否使用发布分支将特定工作范围限定为不同的内容版本。
- 使用 Fabric Git 集成时，哪些分支连接到哪个工作区。
提示
请参阅采用 Git 分支策略，获取有关如何最好地使用分支策略以有效促进协作的具体指导和建议。
提交中的批处理更改
开发内容时，创建者应定期将更改暂存成批次（或组）。 这些更改应解决解决方案的特定工作项（例如功能或问题）。 准备就绪后，内容创建者提交这些暂存的更改。
这样批处理更改有几个优点。
- 它可帮助结构开发，让内容创建者有机会查看和记录已分组的更改。
- 它可改进规划和开发之间的一致性，使链接功能和问题变得更容易，并获取工作进展的透明度。
- 如果对更改进行适当批处理并具有明确的提交消息，技术所有者可以更轻松地查看内容创建者的拉取请求。
暂存和提交对 Power BI 内容的更改时，请考虑以下因素。
- 是从本地存储库还是从 Fabric 工作区暂存和提交更改。
- 在单个存储库中存储多个模型或报表时，将 .pbip 文件放在顶级文件夹中。 这样就可以更轻松地识别和分组所做的更改。
- 使用 gitignore 文件或 .gitattributes 文件忽略无害或无益的元数据更改。 这将确保提交的所有更改都有意义。
提示
有关如何暂存工作并将其提交到 Git 存储库的特定指南和建议，请参阅使用提交保存工作。
创建拉取请求以合并更改
若要合并更改，内容创建者将打开拉取请求。 拉取请求是同行审查的提交，可导致将完成的工作合并到单个解决方案中。 合并可能会导致冲突，必须先解决这些冲突，然后才能合并分支。 拉取请求审查对保创建者遵守组织在开发、质量和合规性方面的标准和做法非常重要。
使用拉取请求合并对 Power BI 内容的更改时，请考虑以下因素。
- 你将使用哪些标准和做法来执行评价（如果有）。 例如，您可以对语义模型使用 Best Practice Analyzer 中的规则。
- 如何查看报表元数据的更改，如果不使用第三方工具，阅读和理解这些更改并不容易。
- 如何解决合并冲突。
清单 - 在规划存储文件的位置时，关键决定和操作包括：
- 选择开发工具：确保你开发内容的方法符合你与其他内容创作者的合作方式以及版本控制的使用方式。
- 在模型和报表的 .pbip 和 .pbix 格式之间进行选择：通常，.pbip 格式对源代码管理更有利，但自助服务用户可以更轻松地找到 .pbix 文件。
- 单独开发语义模型和报表：单独管理不同项类型的更改时，版本控制最有效。 单独开发模型和报表被视为一种良好做法。
- 确定所需的工作区数：使用单独的环境对于内容生命周期管理的成功至关重要。 确保已阐明所需的工作区数量，并进行适当的工作区级别规划。
- 决定如何实现版本控制：决定是采用更简单的方法，使用 SharePoint 或 OneDrive for Business，还是使用 Azure DevOps 来促进源代码控制。
- 设置远程存储库：在 OneDrive 文件夹或 Git 存储库中创建一个结构化的空间，用于存储内容，以便跟踪和管理更改。
- 如果使用源代码管理，请设置 .gitignore 和 .gitattributes 文件：确保设置存储库，以便只跟踪有意义的更改。
- 如果使用源代码管理，请定义分支和合并策略：确保定义明确的流程，了解如何设置和使用源代码管理以最佳支持开发。 避免过度复杂化流程。 而尽可能完善开发团队中当前的工作方式。
相关内容
在本系列的下一篇文章中，了解如何在管理内容生命周期过程中规划和设计内容。