Overview
In enterprise scenarios, BI reports are more of an IT service than just a reporting tool. In the same way, as I have stated many times before, Power BI is a set of services, not just Power BI Desktop. Its development, testing and deployment need to be effectively managed. Therefore, whether it is based on compliance or collaboration efficiency and other considerations, it is harmless for enterprises to implement PBI continuous integration and deployment.
However, currently, there are not many cases of successful implementation of PBI CICD by large and small enterprises at home and abroad. Although I cannot fully understand their practices, based on my own experience and understanding, I have put forward two implementation ideas for readers' reference.
Below I will use a flow chart and some screenshots to help readers understand this idea, but the specific technical operations will not be STEP-BY-STEP here, because there are official website documents that I can figure out by myself, as well as some of the specific technical operations I have posted in previous blogs What has been said in the previous chapter is not necessary to be repeated here.
Plan A
These two solutions are not just theoretical, they are feasible in actual technical implementation. The first plan (Plan A) is the one I personally recommend. It uses Onedrive for business for version control and Power Automate for continuous deployment. The details are as follows:
This solution is suitable for both medium-sized enterprises with a single development team and large enterprises with multiple development teams. For the continuous integration part, the approach is to create a shared Onedrive for the development team, under which different folders can be created for use by different PBI project groups, and configured to the workspace used for the DEV environment:
In this mode, developers do not need to deploy reports to the workspace, but only need to upload them to Onedrive. The benefits are as follows:
1. Use Onedirve to host PBI report files in the DEV environment, and any version changes will be synchronized with the workspace. 2. Conducive
to the management, division of labor, and version collaboration of the PBI development team.
3. Make full use of the version rollback function of Onedrive itself. Features to easily implement PBI file version control
In addition, readers don’t have to worry that the connection and refresh of the PBI data set to the data source are not affected in this mode. In addition, since we only need to configure Onedrive for the DEV workspace, we will wait for it to be subsequently released to UAT or production. After the environment, any version changes in Onedirve will only affect the DEV environment and will not affect UAT and production.
For the continuous deployment part, we can just use Power Automate's Onedrive or Sharepoint triggers. In this way, we can automatically trigger the subsequent workflow every time a new version is uploaded to Onedrive:
Therefore, in the subsequent part of the workflow, we can call the PBI REST API to operate the Power BI content, such as implementing deployment and refreshing the corresponding data set:
Note: For information on using Power Automate to call the Power BI REST API, please refer to this article
Plan B
Plan B is relatively more troublesome. It uses similar platforms such as Github or Bitbucket (hereinafter referred to as Github) as the hosting platform and version management tool for PBI files, and uses dedicated CICD tools such as Azure DevOps or Jenkins (hereinafter referred to as Github). DevOps platforms (collectively referred to as) perform continuous deployment. details as follows:
In this mode, developers push PBI files to Github, and establish pipelines on the DevOps platform to run specific deployment codes to implement CICD. The advantages are as follows:
1. Ability to utilize the rich CICD functions of the DevOps platform
2. Ability to manage other types of enterprise development projects under the same CICD system
3. Ability to integrate with other types of enterprise CICD projects (such as some ETL projects)
However, the disadvantage compared to Plan A is that currently Github cannot be directly configured into the Power BI workspace and cannot be synchronized with the DEV environment in real time like Plan A. Therefore, there is an additional link to deploy to DEV; on the other hand, the implementation of the plan A little more troublesome. The picture below is a screenshot of the successful deployment of Solution B using Jenkins (I did go through a little trouble in the testing process using Jenkins, but the specific steps are beyond the scope of this article. If there is an opportunity, I will elaborate further).
In contrast, the deployment process using Azure DevOps is much smoother. The following figures T1 and T2 are the successful records of automatic deployment of Power BI using two different methods. In actual situations, whenever a developer pushes a new version of PBIX file to Github, the DevOps pipeline is automatically triggered and PBIX is automatically deployed. Deploy to PBI workspace and complete data refresh.
Summarize
Under normal circumstances, I prefer the model A, which is convenient, concise, efficient, and easy to manage. However, if the integration and deployment of PBI need to comply with unified deployment specifications under an enterprise-level framework, or need to be integrated with other projects such as ETL, then option B may be the only option. In addition, when the IT team actually implements this solution, there are many aspects to consider, such as error handling, version rollback, dependencies between data sets and data streams, deployment order, etc. This article aims to provide a starting point and a specific solution. The team must make corresponding adjustments and improvements based on the actual situation.
(This article was first published on the CSDN and D-BI websites )