第8章 维护 分析开发生命周期
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
Power BI 报告发布到工作区后,其内容很少保持不变。报告会不断更新,数据模型会发生变化,新需求也常会涌现。这是好事,因为这意味着用户正在使用该报告,而我们可以改进报告以提供更深入的洞察。
然而,尽管修改单个报告看似简单,但在大型组织中,我们往往需要管理大量报告或数据模型。我们不可能将所有变更都记在脑子里。组织必须以清晰有序的方式追踪变更,这样即使我们离开一年后再回来,也能了解报告在我们缺席期间的修改情况。 此外,我们有时需要将报告或数据集迁移至其他工作区。例如开发、测试和生产环境可能分别对应独立工作区。同时复用报告或模型的组件能节省时间精力,避免每次都从零开始。
本章将探讨如何处理上述所有任务。
首先介绍工作区中的版本控制功能,它能帮助我们追踪变更并保持工作有序。接着探讨Power BI项目(.pbip)文件格式,该格式可更高效地管理报表文件及相关资产。随后我们将关注可复用资产,包括模板文件(.pbit)、数据源文件(.pbids)和共享语义模型。 随后我们将转向部署管道,该机制能以受控且可靠的方式将内容从开发环境推进至测试和生产环境。同时涵盖影响分析功能,使您能在实施变更前预判其对下游组件(如湖仓、数据仓库、数据流和语义模型)的影响。最后我们将探讨如何通过XMLA端点部署和管理语义模型。
为工作区配置版本控制
当长期处理数据或与多名同事协作时,版本控制功能极为实用。 假设我们在编辑报告或数据模型时,某处突然出现故障或异常行为。除了想知道发生了什么,我们还希望查明问题是否曾发生过(比如在上次变更时)。我们可能还想知道是谁做了导致问题的变更,并与其讨论变更原因,而不是简单地回滚变更。
借助版本控制,我们不仅能保存所做的修改,还能追溯具体变更内容,并撤销不符合预期或团队意图的修改。版本控制同时是卓越的文档记录方式,确保即使经过漫长时间,我们仍能清晰追溯操作内容及其执行者。
在 Fabric 中,您有两种版本控制选项:Azure DevOps 和 GitHub。您可以根据个人偏好或组织标准,为每个工作区选择并配置对应方案。两种方案均支持将熟悉的源代码管理工具和流程应用于 Fabric 项目,从而更轻松地保持工作有序、安全,并在需要时随时回滚。
配置 GitHub 与 Azure DevOps 版本控制
在Fabric中,我们可在工作区层面配置版本控制。操作步骤如下:打开需要启用版本控制的工作区(),进入"工作区设置"。在设置菜单中找到"Git集成"选项,可选择配置GitHub或Azure DevOps(参见图8-1)。 每个工作区每次只能关联其中一种选项,因此需根据自身环境或组织需求选择最合适的方案。
图8-1. Fabric工作区设置中的Git 集成部分
我们将从配置 GitHub 集成开始。
配置 GitHub 版本控制
首次打开Git集成菜单时,GitHub图标可能处于灰色不可用状态(默认设置,参见图8-2)。
图8-2. 工作区设置中GitHub集成 默认呈灰色不可用状态
将鼠标悬停在灰色 GitHub 选项上时,会显示提示信息,要求联系 Fabric 管理员为我们启用 GitHub。为此,管理员需进入管理门户并查找 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access