注释
本文是 Power BI 实现规划 系列文章的一部分。 本系列重点介绍如何在 Microsoft Fabric 内实现 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 或 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 文件。 有关详细信息，请参阅本文后面的 “决定内容格式 ”。
Power BI 桌面版
可以使用 Power BI Desktop 创建语义模型或报表，可以将其另存为 .pbix 或 .pbip 文件。 使用 Power BI Desktop 时，还可以使用其他自定义内容文件。 使用 Power BI Desktop 创建内容时，应做出的一些关键决策包括：
- 要使用的文件格式：可以将内容另存为 .pbix 或 .pbip 文件。 有关详细信息，请参阅本文后面的 “决定内容格式 ”。
- 如何管理自定义内容：可以将主题、自定义视觉对象或图像添加到 Power BI Desktop 文件，这可能需要对生命周期管理有不同注意事项。 例如，当内容创建者创建自己的自定义视觉对象时，它们应在单独的文件中保存和管理视觉对象定义。
- 如何管理预览功能：可以选择在 Power BI Desktop 中预览功能或设置，这会更改内容以及如何使用该功能。 例如，可以采取其他步骤来验证使用预览功能的内容。
网页制作
某些内容（如数据流、仪表板和记分卡）只能在 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 报表生成器：用于创建分页报表（.rdl）文件的桌面应用程序。
使用其他工具创建内容时，应做出的一些关键决策包括：
- 如何管理许可证：其他工具可能需要应管理的附加许可证。
- 如何发布内容：其他工具可能需要执行其他步骤来发布内容，例如使用 XMLA 终结点或 Power BI REST API。
确定如何创建内容后，接下来需要选择用于保存和管理它的格式。
确定内容的格式
根据要创建的内容以及将使用的工具，内容可能使用不同的文件格式。 但是，即使在工具中，也必须在不同的格式之间进行选择。 例如，对于使用 Power BI Desktop 创建的报表和语义模型，必须在 .pbix 和 .pbip 文件之间进行选择。 此决策不仅对开发内容的方式以及如何在内容生命周期内管理内容以及如何高效地完成某些开发任务产生功能影响。 例如，如果要在 Power BI Desktop 中开发内容，但使用 Git 集成发布该内容，则必须使用 .pbip 文件。
内容的文件格式可以在内容的生命周期内更改。 例如，你可能最初开始为报表和模型创建 .pbix 文件。 但是，当新内容创建者想要与你协作或想要提高工作效率时，可以切换到其他格式，例如 .pbip 文件。
以下部分概述了必须在 Power BI 中选择的常见格式。
Power BI Desktop （.pbix） 文件格式
Power BI 报表和模型的默认和最常见的格式是 .pbix 文件格式。 此二进制格式易于管理和用于大多数人。 但是，无法打开或使用文件内容来跟踪更改或提高开发人员工作效率。
在以下情况下使用 .pbix 文件格式：
- 你计划使用 OneDrive 刷新功能发布内容。
- 内容创建者希望使用和共享单个文件，而不是多个文件的文件夹（如 .pbip 格式）。
- 内容创建者更喜欢 .pbix 格式，因为它们发现它更简单。
Power BI Projects （.pbip） 文件格式
也可以使用 Power BI 项目 （.pbip） 格式保存内容，而不是 .pbix 文件。 此格式将文件拆分为 文件夹结构。 在 .pbip 的文件夹结构中，可以打开和读取多个元数据文件，提供模型和报表的定义和配置。 由于可以打开和读取文件内容，因此可以手动或以编程方式更改文件内容，从而产生显著的工作效率增强功能。 如果将在 Power BI Desktop 中开发内容，Fabric 中的某些功能（如 Git 集成）还需要使用 .pbip 格式而不是 .pbix 格式。
下图显示了 .pbix 文件和 .pbip 文件的差异：
总之，用户或自动化进程可以查看和修改 .pbip 文件的内容，而无需在 Power BI Desktop 中打开它。 相比之下，.pbix 文件是二进制文件，不支持查看或修改其内容的方法。 在各种情况下，你希望能够查看或更改这些元数据内容，例如：
- 你希望通过跟踪和管理更改来执行源代码管理，并查看已更改的内容。
- 你想要批量进行更改，或搜索文件中的内容。
- 你想要重新使用文件的元素，如视觉对象、表或度量值。
- 你希望查看 Power BI Desktop 用户界面中不可见的属性或设置。
- 你想要在发布内容之前自动执行某些过程，例如扫描元数据以查找最佳做法冲突。
.pbip 文件格式还可以分别将 TMDL 或 PBIR 格式用于语义模型和报表定义，这些格式具有各自的优点和注意事项。
在以下情况下使用 .pbip 文件格式：
- 你计划使用 Git 集成而不是 OneDrive 刷新来发布或部署内容。
- 你计划使用源代码管理来跟踪和管理更改。
- 你计划将 Power BI Desktop 与其他工具结合使用来开发模型或报表。
- 多个内容创建者将协作处理模型或报表。
- 你想要从工作效率增强中获益，并节省时间制作模型或报表。
- 你计划自动执行开发、测试或部署过程的一部分。
- 你想要以不同的方式组织你的模型和报表文件（比如在.Report文件夹中放置多个报表，在.SemanticModel文件夹中放置多个模型）。
小窍门
开发内容时，应意识到自己觉得在浪费时间的情景，例如执行重复性的任务。 在这些方案中，通常可以通过将这些新格式与其他工具（如 Visual Studio Code、Fabric 中的笔记本等）结合使用来节省时间。
表格模型定义语言 （.tmdl） 文件格式
将模型另存为 .pbip 时，可以选择将其另存为单个 .bim 文件，该文件使用表格模型脚本语言（TMSL），或在多个 .tmdl 文件的文件夹结构中，该文件使用新的表格模型定义语言。 TMDL 对语义模型定义使用类似于 YAML 的语法，以便更轻松地读取和管理模型的更改。
下面是 TMDL 格式外观的示例：
新的 TMDL 格式的一些优点如下：
- 可以更好地使用源代码管理和 Git 集成，因为模型元数据更简洁、结构化且更易于阅读。
- 无需创建冲突即可更轻松地合并更改。
- 可以提高某些报告任务的效率，例如在模型之间重新使用或复制模型对象（如日期表）。
下面是使用 TMDL 格式的源代码管理的示例：
在以下情况下使用 TMDL 格式：
- 你计划使用源代码管理来跟踪和管理更改。
- 你希望通过进行元数据更改来提高开发人员工作效率。
- 可以使用其他工具（如 Visual Studio Code 或表格编辑器）开发语义模型。
注释
TMDL 格式与 Power BI Desktop 中的 TMDL 视图不同：
- TMDL 是语义模型的语言和元数据格式。
- TMDL 视图 是 Power BI Desktop 中的脚本界面，用于对模型进行编程更改。 它使用的 TMDL 脚本语法与 TMDL 格式文件的 YAML 类似。 您不需要使用 TMDL 格式就可以从 TMDL 视图中受益。
Power BI 增强型报表（PBIR）格式。
将内容另存为 .pbip 文件时，可以选择使用默认报表格式或 新的 PBIR 格式。 这种新格式提供了多种优势，可以增强开发人员的工作效率和协作，尤其是在将 PBIR 格式与 .pbip 文件一起使用时。
下面是 PBIR 格式的一个示例：
使用 PBIR 格式的一些优点如下：
- 可以更好地使用源代码管理和 Git 集成，因为报表元数据更简洁、结构化且更易于阅读。
- 可以提高某些报告任务的效率，例如：
- 通过复制 visual.json，在页面之间重新使用或复制视觉元素。
- 在不同报表之间重用或复制页面。
- 同时查找和替换自定义颜色、字段和其他视觉配置。
- 修复在表之间进行重命名或移动字段后受损的视图。
- 可以向报表元数据添加元数据注释，以方便支持持续集成/持续部署（CI/CD）的某些自动化或任务。
- 可以利用像语义链接实验室这样的工具，它们在新的PBIR格式下更加实用。
在以下情况下使用 PBIR 格式：
- 你计划使用源代码管理来跟踪和管理更改。
- 你希望通过更改元数据来提高报表创建者工作效率。
- 你想要对报表进行编程或自动更改。
谨慎
在使用 PBIR 格式之前，请确保先检查 限制和注意事项 。 这些限制和注意事项会随时间而变化，因此，如果某些项目阻止你满足 Power BI 内容的特定要求，请定期检查。
此外，无论其格式如何，所有报表元数据都有可能包含数据点。 有关详细信息，请参阅 PBIR 文件夹和文件。
Power BI 模板 （.pbit） 文件格式
还可以将 Power BI 报表或语义模型另存为 .pbit 文件。 但是，.pbit 文件旨在重新使用特定的报表布局或模型结构。 在开发期间，不应使用 .pbit 格式保存和管理 Power BI 内容。 相反，当想要创建可重用模板以与组织中的其他人共享时，应使用 .pbit 文件。
其他格式
在 Power BI 中开发其他内容（如仪表板、数据流或分页报表）时，如果在 Fabric 中开发项，则可能没有内容文件。 或者，只能将项的定义保存到源代码管理中。 有关详细信息，请参阅此系列上一篇文章中的 “决定文件存储位置 ”。
决定如何设置和使用工作区
开发内容时，应使用多个工作区（或阶段）将组织使用的生产内容与开发或验证的内容分开。 为内容使用单独的工作区有几个优点：
- 可以开发和测试内容，而不会影响当前使用的内容。 这避免了对生产中内容造成意外中断的更改。
- 可以使用单独的资源来开发和测试内容，例如使用单独的 数据网关 或 Fabric 容量。 这可以避免用于开发和测试的资源中断生产工作负荷，从而导致数据刷新或报告速度缓慢。
- 通过为每个阶段设置独立的环境，可以创建一个更有结构化的过程来开发、测试和发布内容。 这有助于提高工作效率。
在 Fabric 和 Power BI 中，建议使用单独的 Fabric 工作区，如 租户级 和 工作区级 规划文章中所述。
重要
使用单独的环境是确保内容生命周期管理方法成功的重要步骤。
可通过多种方式使用 Fabric 工作区来分隔环境。 通常，除了本地环境外，还可以使用两个或多个工作区来管理其生命周期内的内容。
在规划如何在内容整个生命周期内使用单独的工作区时回答以下问题：
- 需要多少个工作区？
- 是否 按项类型分隔工作区？
- 谁有权访问每个工作区？
- 工作区是否属于 Fabric 部署管道，或者是否使用其他方法（例如使用 Azure Pipelines）来协调部署？
- 如何管理 跨工作区发布？ 例如，是否需要确保报表的测试工作区中的报表连接到数据项单独测试工作区中的语义模型？
- 是否还需要为生产工作区中的项目使用单独的支持资源，例如单独的本地数据网关群集？
以下部分简要概述了可以采用的不同方法来分隔工作区，以便简化生命周期管理。
注释
以下部分重点介绍如何设置和使用单独的工作区。 可以使用以下四种方法之一将内容部署到这些工作区：
- 通过 Power BI Desktop 进行发布。
- 使用 Fabric 发布管道从另一个工作区发布内容。
- 使用 Git 集成从远程 Git 存储库同步内容。
- 使用 Fabric 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 测试计划：允许您设计测试以验证解决方案，并通过 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 的一部分。 也可以使用 GitHub，而不是 Azure DevOps。 在这两种方法中，将本地内容文件添加到远程存储位置，以帮助跟踪和管理更改。 建议仅将 SharePoint 或 OneDrive 用于更小、更简单的项目，因为它缺少支持更大或更复杂的方案的功能和稳定性。
下面是一些常规注意事项，可帮助你设置和使用版本控制。
- 警报：应在其他人添加、删除或修改关键文件时设置警报。
- 范围：明确定义远程存储位置的范围。 理想情况下，远程存储位置的范围与用于将内容传送给使用者的下游工作区和应用的范围相同。
- 访问权限：应使用与为 部署管道权限 和 工作区角色设置的类似权限模型来设置对远程存储位置的访问权限。 内容创建者需要访问远程存储位置。
- 文档：将文本文件添加到远程存储位置，以描述远程存储位置及其用途、所有权、访问和定义的进程。
以下各节介绍每个方法和关键注意事项，以确定应使用哪种方法。
使用 SharePoint 或 OneDrive for Work 和 School 进行版本控制
SharePoint 具有文件的内置版本控制。 内容创建者可以在本地开发语义模型或报表，其更改将同步到 SharePoint 或 OneDrive for Work 和 School 文档库。
小窍门
仅在更简单、更小的方案（如 自助服务内容发布）中使用 SharePoint 或 OneDrive 进行版本控制。 对于更大或更复杂的方案，应考虑 使用远程 Git 存储库执行源代码管理。
下图概述了如何使用 SharePoint 或 OneDrive 执行版本控制。
此图描述了以下过程和组件。
| 物品 | 说明 |
|---|---|
|
|
内容创建者在本地环境中开发语义模型和报表，并将这些模型和报表另存为 .pbix 文件。 |
|
|
准备就绪后，内容创建者会保存其更改，这些更改会同步到远程 SharePoint 或 OneDrive for Work 和 School 库。 |
|
|
在远程库中，内容创建者跟踪文件级更改，从而促进版本控制。 |
|
|
内容创建者可以将已发布的语义模型或报表链接到 .pbix 文件，以方便 OneDrive 刷新。 OneDrive 刷新每小时自动发布内容更改。 |
|
|
在 Fabric 工作区中，内容创建者在 OneDrive 刷新完成后看到对 Power BI 内容的更改。 |
重要
只能使用包含语义模型或报表的 SharePoint 或 OneDrive for Power BI Desktop 文件执行版本控制。 对于其他 Power BI 项类型（如数据流）或 Fabric 项目类型（如笔记本），你无法轻松执行版本控制。 对于这些其他项类型，应使用远程 Git 存储库（如 Azure Repos）执行版本控制。
总之，内容创建者可以将已发布的语义模型或报表 链接到 存储在 SharePoint 或 OneDrive for Work 和 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 和 School 进行版本控制时，签入和签出文件有助于改进内容创建者之间的协作。 如果使用多个内容创建者签入和签出文件，则可以修改 SharePoint 网站库以查看上次更新和上次签入的注释。
版本历史记录
确保将内容备份到单独的位置，以防 SharePoint 网站文档库发生意外中断。 还应设置 SharePoint 网站中保留的版本数的限制，并删除旧版本。 这可确保版本历史记录保持有意义，并且不会占用太多空间。
对于更复杂的版本控制，可以将文件存储在远程存储库（如 Azure Repos）中，并使用源代码管理管理更改。
使用远程 Git 存储库进行源代码管理
远程 Git 存储库有助于对文件的源代码管理，这样内容创建者就可以使用更多选项来跟踪和管理更改。 简言之，内容创建者可以在本地或 Power BI 服务中开发内容，然后将这些更改提交并推送到远程 Git 存储库，例如 Azure Repos 或 GitHub。
注释
还可以在不使用 Git 集成的情况下对内容执行源代码管理。 在此方案中，你仍跟踪和管理远程 Git 存储库中的内容更改，但使用 REST API 或 XMLA 读/写终结点部署内容。 有关部署内容的方法的详细信息，请参阅 阶段 4：部署内容。
下图概述了如何通过在本地开发内容来执行源代码管理，然后将更改提交到远程存储库，后者可以使用 Git 集成与 Fabric 工作区同步。
此图描述了以下过程和组件。
| 物品 | 说明 |
|---|---|
|
|
内容创建者在本地环境中开发语义模型和报表，并将这些模型和报表另存为 .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，内容创建者需要使用 命令行界面（CLI） 或 SCM 的图形用户界面（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 或 GitHub 配合使用的主要好处是内容创建者之间的协作以及有关内容更改和部署的更多自定义和监督。
下图描述了 Azure DevOps 如何实现与源代码管理协作的高级概述。 还可以使用 GitHub Enterprise 而不是 AzureDevOps，这将涉及执行类似功能的不同服务。
注释
上图描述了如何使用 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 存储库的具体指南和建议，请参阅“保存你的工作与提交”。
创建拉取请求以合并更改
若要合并更改，内容创建者将打开 拉取请求。 拉取请求是用于对等评审的提交，可促成将完成的工作整合到单个解决方案中。 合并可能会导致冲突，必须在合并分支之前解决冲突。 拉取请求评审对于确保创建者遵守开发、质量和合规性的组织标准和做法非常重要。
使用 pull 请求合并对 Power BI 内容的更改时，请考虑以下因素。
- 你将使用哪些标准和做法来执行评审（如果有）。 例如，可以使用 最佳做法分析器 中的规则进行语义模型。
- 如何查看报表元数据的更改，如果不使用第三方工具，就不容易阅读和理解这些更改。
- 如何 处理和解决合并冲突。
清单 - 规划存储文件的位置时，关键决策和作包括：
- 选择开发工具：确保开发内容的方法与你将如何与其他内容创建者协作并使用版本控制保持一致。
- 在模型和报表的 .pbip 和 .pbix 格式之间进行选择：通常，.pbip 格式对源代码管理更有利，但自助服务用户可以更轻松地找到 .pbix 文件。
- 单独的语义模型和报表开发：单独管理不同项类型的更改时，版本控制最有效。 分离模型和报表开发 被认为是一种良好做法。
- 确定需要多少个工作区：使用单独的环境对于内容生命周期管理的成功至关重要。 确保阐明了需要多少工作区并执行适当的 工作区级别规划。
- 决定如何实现版本控制：使用 SharePoint 或 OneDrive for Business，或使用 Azure DevOps 简化源代码管理，在更简单的方法之间进行决定。
- 设置远程存储库：在 OneDrive 文件夹或 Git 存储库中创建结构化空间，在其中存储内容以跟踪和管理更改。
- 如果使用源代码管理，请设置 .gitignore 和 .gitattributes 文件：确保设置存储库，以便只跟踪有意义的更改。
- 如果使用源代码管理，请定义分支和合并策略：确保定义明确的流程，了解如何设置和使用源代码管理以最佳支持开发。 避免过度复杂化进程。 相反，请尝试补充开发团队中当前的工作方式。
相关内容
在本系列的下一篇文章中，了解如何在管理内容生命周期过程中验证内容。