乐趣区

关于devops:简谈企业Power-BI-CICD实施框架

jiezi

概述

在企业场景中，BI 报表更多地作为一项 IT 服务，而绝不仅是报表工具而已。同理，正如我此前屡次说明，Power BI 是一套服务，也绝不仅是 Power BI Desktop，它的开发，测试与部署，都须要失去无效的治理。因此，无论是基于合规性，还是合作效率等方面来考量，企业施行 PBI 继续集成与部署，百利而无一害。

然而，以后国内外的大小企业，曾经胜利施行 PBI CI/CD 的案例并不多，我虽无奈齐全理解他们的做法，但基于本身的教训和了解，我提出了两种施行思路，供读者参考。
下文我会通过流程图和一些截图来帮忙读者了解这种思路，但具体的技术操作此处不会 STEP-BY-STEP，因为官网文档有的，本人轻易能摸索进去的，以及一些我在此前博客中讲过的，没有在这里反复的必要。

计划 A

这两种计划并不只是实践，他们在理论的技术施行上都是行得通的。其中第一种计划（Plan A）是我集体比拟举荐的计划，它应用 OneDrive for business 做版本控制，用 Power Automate 做继续部署，具体如下：

这种计划无论是对于领有单个开发团队的中小型组织，还是多个开发团队的大型企业，都是实用的。对于继续集成的局部，其做法即是为开发团队创立一个共享 OneDrive，在该 OneDrive 下能够创立不同的 folder 以供不同的 PBI 项目组应用，并将其配置到用于 DEV 环境的工作区：

在该模式下，开发者无需将报表部署到工作区，而只须要将其上传到 OneDrive 即可，其益处如下：

  1. 应用 OneDrive 托管 DEV 环境中的 PBI 报表文件，任何版本变动均与该工作区同步
  2. 有利于 PBI 开发团队的治理，分工，以及版本协同
  3. 充分利用 OneDrive 自身具备的版本回退的性能个性，轻松实现 PBI 文件版本控制

此外，读者也不用放心的是，此模式下 PBI 数据集与数据源的连贯以及刷新是不受影响的，此外，因为咱们仅需为 DEV 工作区配置 OneDrive，故而待其后续公布到 UAT 或生产环境后，OneDrive 中的任何版本变动都只会影响 DEV 环境，不会影响 UAT 和生产。

继续部署的局部，咱们恰好能够利用 Power Automate 的 OneDrive 或 Sharepoint 的触发器，这样，咱们能够实现每当一个新的版本上传到 OneDrive 后，主动触发后续的工作流：

因而在工作流的后续局部，咱们能够调用 PBI REST API 对 Power BI 内容进行操作，比方施行部署并刷新对应的数据集：

注：对于利用 Power Automate 调用 Power BI REST API，可参考此文
https://d-bi.gitee.io/pbi-res…

计划 B

Plan B 相对而言则略麻烦一点，它应用 GitHub 或 Bitbucket 等相似平台 (下文以 GitHub 代称) 作为 PBI 文件的托管平台与版本管理工具，而应用 Azure DevOps 或 Jenkins 这种专用的 CI/CD 工具（下文以 DevOps 平台统称）进行继续部署。具体如下：

在该模式下，开发者将 PBI 文件 Push 到 GitHub，并在 DevOps 平台建设管道运行具体的部署代码来实现 CI/CD，其劣势如下：

  1. 可能利用 DevOps 平台丰盛的 CI/CD 性能
  2. 可能与企业其余类型的开发我的项目在同一个 CI/CD 体系下进行治理
  3. 可能与企业其余类型的 CI/CD 我的项目（比方一些 ETL 我的项目）进行集成

但相比 Plan A 有余的点在于目前 GitHub 不能间接配置到 Power BI 工作区，无奈像计划 A 那样与 DEV 环境实时同步，因而多了一个部署到 DEV 的环节；另一方面则是该计划施行起来要略微麻烦些。下图是我应用 Jenkins 实现计划 B 的部署胜利截图（我在应用 Jenkins 的测试过程中的确费了一点周折，但具体步骤不在本文领域内，若有机会另行赘诉）。

相比之下，应用 Azure DevOps 做部署的过程则顺利得多。下图 T1 和 T2 是我别离用两种不同办法实现 Power BI 主动部署的胜利记录，理论状况下，每当开发者将新版本的 PBIX 文件推送到 GitHub，则 DevOps 管道主动被触发，将 PBIX 主动部署到 PBI 工作区并实现数据刷新。

总 结

通常状况下，我更偏向于计划 A 的模式，它不便，扼要，高效，易于治理。但如果 PBI 的集成与部署须要合乎企业级框架下对立的部署标准，或者须要与 ETL 等其余我的项目进行集成的须要，那么计划 B 或者是惟一抉择。此外，IT 团队理论施行此计划时，要思考的方面还很多，比方报错解决，版本回退，数据集与数据流间的依赖关系和部署秩序等等问题，而本文旨在抛砖引玉，具体的计划则肯定是须要团队根据理论状况做相应调整和欠缺。

微软最有价值专家（MVP）


微软最有价值专家是微软公司授予第三方技术专业人士的一个寰球奖项。29 年来，世界各地的技术社区领导者，因其在线上和线下的技术社区中分享专业知识和教训而取得此奖项。

MVP 是通过严格筛选的专家团队，他们代表着技术最精湛且最具智慧的人，是对社区投入极大的激情并乐于助人的专家。MVP 致力于通过演讲、论坛问答、创立网站、撰写博客、分享视频、开源我的项目、组织会议等形式来帮忙别人，并最大水平地帮忙微软技术社区用户应用 Microsoft 技术。

更多详情请登录官方网站：
https://mvp.microsoft.com/zh-cn


长按辨认二维码
关注微软中国 MSDN

点击退出微软 MVP~

退出移动版