简谈企业Power BI CI/CD实施框架

简谈企业Power BI CI/CD实施框架_第1张图片

概述

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

然而,当前国内外的大小企业,已经成功实施PBI CI/CD的案例并不多,我虽无法完全了解他们的做法,但基于自身的经验和理解,我提出了两种实施思路,供读者参考。
下文我会通过流程图和一些截图来帮助读者理解这种思路,但具体的技术操作此处不会STEP-BY-STEP, 因为官网文档有的,自己轻易能摸索出来的,以及一些我在此前博客中讲过的,没有在这里重复的必要。

方案A

这两种方案并不只是理论,他们在实际的技术实施上都是行得通的。其中第一种方案(Plan A)是我个人比较推荐的方案,它使用OneDrive for business做版本控制,用Power Automate做持续部署,具体如下:
简谈企业Power BI CI/CD实施框架_第2张图片
这种方案无论是对于拥有单个开发团队的中小型组织,还是多个开发团队的大型企业,都是适用的。对于持续集成的部分,其做法即是为开发团队创建一个共享OneDrive,在该OneDrive下可以创建不同的folder以供不同的PBI项目组使用,并将其配置到用于DEV环境的工作区:
简谈企业Power BI CI/CD实施框架_第3张图片
在该模式下,开发者无需将报表部署到工作区,而只需要将其上传到OneDrive即可,其好处如下:

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

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

持续部署的部分,我们恰好可以利用Power Automate的OneDrive或Sharepoint的触发器,这样,我们可以实现每当一个新的版本上传到OneDrive后,自动触发后续的工作流:
简谈企业Power BI CI/CD实施框架_第4张图片

因此在工作流的后续部分,我们可以调用PBI REST API对Power BI内容进行操作,比如实施部署并刷新对应的数据集:
简谈企业Power BI CI/CD实施框架_第5张图片

注:关于利用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平台统称)进行持续部署。具体如下:
简谈企业Power BI CI/CD实施框架_第6张图片

在该模式下,开发者将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的测试过程中确实费了一点周折,但具体步骤不在本文范畴内,若有机会另行赘诉)。
简谈企业Power BI CI/CD实施框架_第7张图片

相比之下,使用Azure DevOps做部署的过程则顺利得多。下图T1和T2是我分别用两种不同方法实现Power BI自动部署的成功记录,实际情况下,每当开发者将新版本的PBIX文件推送到GitHub,则DevOps管道自动被触发,将PBIX自动部署到PBI工作区并完成数据刷新。

简谈企业Power BI CI/CD实施框架_第8张图片

总 结

通常情况下,我更倾向于方案A的模式,它方便,简明,高效,易于管理。但如果PBI的集成与部署需要符合企业级框架下统一的部署规范,或者需要与ETL等其他项目进行集成的需要,那么方案B或许是唯一选择。此外,IT团队实际实施此方案时,要考虑的方面还很多,比如报错处理,版本回退,数据集与数据流间的依赖关系和部署次序等等问题,而本文旨在抛砖引玉,具体的方案则一定是需要团队依据实际情况做相应调整和完善。


微软最有价值专家(MVP)


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

MVP是经过严格挑选的专家团队,他们代表着技术最精湛且最具智慧的人,是对社区投入极大的热情并乐于助人的专家。MVP致力于通过演讲、论坛问答、创建网站、撰写博客、分享视频、开源项目、组织会议等方式来帮助他人,并最大程度地帮助微软技术社区用户使用 Microsoft 技术。

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


长按识别二维码
关注微软中国MSDN

点击加入微软MVP~

你可能感兴趣的:(devopsmicrosoft)