Fabric 中生命周期管理的最佳做法
本文为在 Microsoft Fabric 中管理其内容的整个生命周期的数据 分析创建者提供指导。 本文重点介绍如何将 Git 集成 用于源代码管理，并将部署管道用作发布工具。 有关企业内容发布的一般指南，请参阅 企业内容发布。
本文分为四个部分：
内容准备 - 准备进行生命周期管理的内容。
开发 - 了解在部署管道开发阶段创建内容的最佳方式。
测试 - 了解如何使用部署管道测试阶段来测试环境。
生产 - 使内容可供使用时，利用部署管道生产阶段。
内容准备的最佳做法
若要将内容准备做到最好，以便在整个生命周期进行持续管理，请在执行以下操作之前查看本节中的信息：
将内容发布到生产环境。
开始为特定工作区使用部署管道。
在团队之间分离开发
组织中的不同团队通常具有不同的专业知识、所有权和工作方法，即使在处理同一项目时也是如此。 设置边界非常重要，可以同时让每个团队能够独立地按自己的方式工作。 考虑为不同的团队提供单独的工作区。 使用单独的工作区，每个团队可以具有不同的权限、使用不同的源代码管理存储库，以及以不同的节奏将内容交付到生产环境。 大多数项可以跨工作区连接和使用数据，因此不会阻止对同一数据和项目进行协作。
规划权限模型
Git 集成和部署管道需要的权限不同于工作区权限。 阅读 Git 集成和部署管道的权限要求。
若要实现安全且简单的工作流，请规划谁有权访问正在使用的环境的每个部分，包括 Git 存储库和管道中的开发/测试/生产阶段。 要考虑的一些注意事项包括：
谁应该有权访问 Git 存储库中的源代码？
有权访问管道的用户可以在每个阶段执行哪些操作？
谁负责测试阶段审核内容？
测试阶段审阅者是否应该有权访问管道？
谁负责监督生产阶段的部署？
你要将哪个工作区分配给管道或连接到 git？
你要将工作区连接到哪个分支？ 为该分支定义的策略是什么？
工作区是否由多个团队成员共享？ 他们应该直接在工作区中进行更改，还是仅通过拉取请求进行更改？
要把你的工作区分配到哪个阶段？
是否需要对所分配工作区的权限进行修改？
将不同的阶段连接到不同的数据库
生产数据库应始终稳定且可用。 最好不要用 BI 创建者为其开发或测试语义模型生成的查询重载生产数据库。 生成用于开发和测试的单独数据库，以保护生产数据，并且可以避免因整个生产数据量导致开发数据库过载。
将参数用于将在阶段之间更改的配置
尽可能将参数添加到可能在开发/测试/生产阶段之间发生更改的任何定义。 将更改移动到生产环境时，使用参数有助于轻松更改定义。 虽然仍然没有统一方法来管理 Fabric 中的参数，但我们建议在支持任何类型的参数化的项上使用它。
参数具有不同的用途，例如定义与数据源或 Fabric 中的内部项的连接。 它们还可用于更改查询、筛选器和向用户显示的文本。
在部署管道中，可以配置参数规则，为每个部署阶段设置不同的值。
部署管道测试阶段的最佳做法
本部分提供有关如何处理部署管道并将其用于开发阶段的指导。
将工作备份到 Git 存储库
通过 Git 集成，任何开发人员都可以通过将工作提交到 Git 中来备份其工作。 若要在 Fabric 中正确备份工作，下面是一些基本规则：
请确保有一个独立环境，以便其他人在提交工作之前不会覆盖你的工作。 这意味着在桌面工具（如 VS Code、Power BI Desktop 或其他工具 ）中工作，或在其他用户无法访问的单独工作区中工作。
提交到由你创建且其他开发人员未使用的分支。 如果使用工作区作为创作环境，请阅读有关使用分支工作的信息。
一起提交必须一起部署的更改。 此建议适用于单个项，或与同一更改相关的多个项。 将所有相关更改一起提交有助于稍后部署到其他阶段、创建拉取请求或还原更改。
大型提交可能会达到最大提交限制。 请注意一起提交的项数或项的一般大小。 例如，添加大型图像时，报表可能会变大。 将大型项目存储在源代码管理系统中是一种不良做法，即使它能正常工作也是如此。 如果项目具有大量静态资源（例如图像），请考虑如何能减小其大小。
回滚更改
备份工作后，在某些情况下，你可能想要还原到以前的版本，并在工作区中还原它。 可通过几种方法还原到以前的版本：
“撤消”按钮：“撤消”操作是还原所做即时更改（只要尚未提交）的简单快捷方法。 还可以单独撤消每个项。 详细了解撤消操作。
还原到较旧的提交：没有直接方法可以在 UI 中返回到以前的提交。 最佳选择是使用 git 还原或 git 重置将较旧的提交提升为 HEAD。 执行此操作将显示源代码管理窗格中有更新，并且你可以使用该新提交更新工作区。
由于数据并不存储在 Git 中，请记住，将数据项还原到旧版本可能会破坏现有数据，因此可能需要丢弃数据或操作可能失败。 在还原更改之前，请提前检查此项。
使用“专用”工作区
如果要隔离工作，请使用单独的工作区作为隔离环境。 详细了解如何在使用分支中隔离工作环境。 为获得最佳工作流和团队，请考虑以下几点：
设置工作区：在开始之前，请确保可以创建新的工作区）如果尚未创建），可以将其分配给 Fabric 容量，并且你有权访问数据以在工作区中工作。
创建新分支：从主分支中创建新分支，以便获得最新版本的内容。 此外，请确保连接到分支中的正确文件夹，以便可以将正确的内容拉取到工作区中。
小而频繁的更改：Git 最佳做法是进行易于合并且不太可能发生冲突的小型增量更改。 如果这无法实现，请确保从主更新分支，以便可以先自行解决冲突。
配置更改：如有必要，请更改工作区中的配置，以帮助提高工作效率。 某些更改可能包括项之间的连接，或者对不同数据源的连接，或者对给定项上的参数的更改。 请记住，提交的任何内容都会成为提交的一部分，并且可能会意外地合并到主分支中。
使用客户端工具编辑工作
对于支持它的项和工具，使用客户端工具进行创作可能更容易，例如适用于语义模型和报表的 Power BI Desktop、适用于笔记本的 VS Code 等。这些工具可以用作你的本地开发环境。 完成工作后，将更改推送到远程存储库，并同步工作区以上传更改。 只需确保使用所创作项目的受支持结构即可。 如果不确定，请先克隆内容已同步到工作区的存储库，然后从该工作区开始创作，其中结构已就位。
管理工作区和分支
由于工作区一次只能连接到单个分支，因此建议将其视为 1:1 映射。 但是，若要减少所需的工作区数量，请考虑以下选项：
如果开发人员设置了具有所有必需配置的专用工作区，他们可以使用该工作区继续为将来创建的任何分支。 冲刺结束时，将合并更改并启动新的新任务，只需将连接切换到同一工作区上的新分支即可。 如果突然需要在冲刺阶段修复 bug，也可以执行此操作。 可将其视为 Web 上的工作目录。
使用客户端工具（如 VSCode、Power BI Desktop 或其他工具）的开发人员不一定需要工作区。 他们可以在本地创建分支并将更改提交到该分支，将这些分支推送到远程存储库，并创建拉取请求到主分支，所有这些都不需要工作区。 工作区仅需要作为测试环境来检查一切在现实场景中正常工作。 这何时应该发生由你决定。
复制 Git 存储库中的项
若要复制 Git 存储库中的项，请执行以下操作：
- 复制整个项目录。
- 将 logicalId 更改为该连接工作区的独有内容。
- 更改显示名称以将其与原始项区分开，并避免出现“显示名称重复”错误。
- 如有必要，请更新任何依赖项中的 logicalId 和/或显示名称。
部署管道测试阶段的最佳做法
本部分提供有关如何处理部署管道测试阶段的指导。
模拟生产环境
请务必了解建议的更改将如何影响生产阶段。 部署管道测试阶段允许你模拟真实的生产环境进行测试。 或者，可以通过将 Git 连接到其他工作区来模拟这种情况。
确保在测试环境中解决以下三个因素：
数据量
使用量
类似于生产环境的容量
测试时，可以使用与生产阶段相同的容量。 但是，使用相同的容量可能会使生产在负载测试期间不稳定。 为避免生产不稳定，请使用资源中与生产容量类似的不同容量进行测试。 为了避免产生额外的费用，请使用仅对测试时间付费的容量。
使用包含实际数据源的部署规则
如果使用测试阶段来模拟实际数据使用情况，最好是分离开发和测试数据源。 开发数据库应相对较小，测试数据库应尽量与生产数据库相似。 如果不通过部署管道工作，请使用数据源规则在测试阶段切换数据源或参数化连接。
检查相关项
所做的更改也会影响依赖项。 在测试过程中，请确认所做更改不会影响或破坏现有项目的性能，这可能取决于更新的项目。
可以使用影响分析轻松找到相关的项。
更新数据项
数据项是存储数据的项。 Git 中项的定义定义了数据的存储方式。 更新工作区中的项时，我们会将其定义导入工作区，并将其应用于现有数据。 Git 和部署管道的数据项更新操作是相同的。
由于在应用定义更改时，不同的项在保留数据方面具有不同的功能，因此在应用更改时要注意。 以下是有助于以最安全的方式应用更改的一些做法：
事先知道更改是什么，以及它们可能对现有数据产生的影响。 使用提交消息描述所做的更改。
若要查看该项如何处理测试数据的更改，请首先将更改上传到开发或测试环境。
如果一切顺利，建议在过渡环境中检查实际数据（或尽可能接近实际数据），以尽量减少生产中的意外行为。
更新生产环境时，请考虑最佳时机，以尽量减少任何错误可能对使用数据的业务用户造成的损害。
部署后，在生产环境中进行部署后测试，以验证一切是否按预期工作。
某些更改将始终被视为重大更改。 希望前面的步骤有助于在生产之前跟踪它们。 制定计划，了解如何应用生产中的更改并恢复数据，以恢复正常状态，并最大程度地减少业务用户的停机时间。
测试应用程序
如果要通过应用向客户发布内容，请在应用的新版本投入生产之前，对该版本进行审查。 由于每个部署管道阶段都有自己的工作区，因此，你可以轻松地发布和更新应用，以用于开发和测试阶段。 发布和更新应用将使你能够从最终用户的角度来测试应用。
重要
部署过程不包括更新应用内容或设置。 若要应用对内容或设置的更改，请在所需的管道阶段手动更新应用。
部署管道生产阶段的最佳做法
本部分提供有关部署管道生产阶段的指导。
管理可部署到生产环境的人员
由于应谨慎处理到生产环境的部署，因此，最好让特定人员管理此敏感操作。 但是，你可能希望特定工作区的所有 BI 创建者都可以访问管道。 使用生产工作区权限管理访问权限。 其他用户可通过生产工作区查看者角色来查看工作区中的内容，但不能通过 Git 或部署管道进行更改。
此外，限制对存储库或管道的访问权限，只对属于内容创建过程一部分的用户启用权限。
设置规则，确保生产阶段的可用性
部署规则是确保生产中的数据始终连接在一起并可供用户使用的强大方式。 应用部署规则后，就可以运行部署，同时保证客户不受干扰地看到相关信息。
请确保为语义模型中定义的数据源和参数设置生产部署规则。
更新生产应用
通过 UI 在管道中进行部署会更新工作区内容。 要更新关联的应用，请使用部署管道 API。 无法通过 UI 更新应用。 如果使用的是内容分发应用，在部署到生产后不要忘记更新应用，这样最终用户就可以立即使用最新版本。
使用 Git 分支部署到生产环境
由于存储库充当“单一真实源”，因此某些团队可能希望直接从 Git 将更新部署到不同的阶段。 这可以通过 Git 集成实现，但需要考虑以下几点：
建议使用发布分支。 每次部署之前，都需要持续更改工作区与新版本分支的连接。
如果生成或发布管道要求在部署到工作区之前更改源代码，或在生成环境中运行脚本，那么将工作区连接到 Git 不起作用。
部署到每个阶段后，请确保更改特定于该阶段的所有配置。
快速修复内容
有时，生产中存在需要快速修复的问题。 不先测试就部署修复程序是一种不良做法。 因此，始终在开发阶段实现修补程序，并将其推送到部署管道的其他阶段。 部署到开发阶段后，可以在将修补程序部署到生产环境之前检查它是否正常工作。 跨管道部署只需几分钟时间。
如果使用 Git 部署，建议遵循采用 Git 分支策略中所述的做法。