Hi
Here's the headline request. More detail follows it.
Headline
Does anyone have any suggestions/best practice/adopted procedure for making the development and deployment of PowerBi embedded reports part of a Continuous Integration build/deploy pipeline?
Detail
I work for a small team that develops/supports/maintains our company's CRM system. Small team though we are the app is quite large. Its a secure intranet - nothing public facing. We have a product owner, a BA/Tester and 2 devs (Of which I am one). We have 3 environments
1) Dev - just accessible by us two devs
2) QA - Accessible by the BA for testing and by stakeholders in the company who request the new features for UAT
3) Prod - General release
Currently our system is, that we work from a backlog of tasks that the BA has gathered from users for new features fixes etc.
We develope the queries in SQL and the pages are MVC C# Javascript MVVM etc and, once done, we check in the files to TFS which kicks of a build.
On completion of the build we use a Powershell script to push the files and database dacpac (build artifacts) to deploy the build to our QA environment.
Once done the QA guy tests the work, shows it to the stakeholders for UAT and if all ok lets us devs know all is ready for release. Than at an out of hours time we'll use the Powershell script once more to deploy the same build to our production environment.
So in effect the "release" procedure is a one step action with all the artifacts of the build deployed easily. We work in an AGILE manner and try to break down large tasks into smaller discrete ones and regularly release the new functionality.
So now we are introducing Power BI into our application by embedding reports into some of our pages and have a situation where the reports are developed (and therefore some of the artifacts of our build/app (e the PBIX and Dataset ) outside of Visual Studio TFS. Ideally we'd like to bring the development of Power BI reports into our system and fit it into our dev/qa/prod release pipeline. This is important to us for matters like version control, we cant have ad hoc modifications to Power BI reports being made and published put of snync with main development.
So after some initial thinking I envisage something along these lines
(We'll be using the import method to get data, refreshed several time a day through a gateway)
The BA will act as the power user of PowerBi Desktop and be the main author of the visualisations/reports/dashboards
1) The BA gathers the requirements for a new report from stakeholders and puts together an initial spec
2) The BA meets with the Devs to discuss the report and refine the detail with regard to the columns required so they can build some sql/a view/procedure to base the data source on. Custom filters, events etc will also be discussed.
3) The BA refines the spec, and gives to devs.
4) The devs produce this sql, check it in, the build is deployed to the QA server where it is accessible by the BA
5) The BA develops the report by using the new data source and publishes it to a QA workspace. The team and stakeholders will be member of this workspace and able to see/approve the report. Tweaks can be made.
6) The BA downloads the PBIX to his local machine and checks it into TFS (Using TFS power tools). This will be the file used for deployment to prod. If any tweaks are made to the report before release the new pbix is checked in.
7) Meanwhile the devs develope the page that will host the embedded report. They will know the app Id, group id etc and will get the new report Id from the url in the published QA environment.
So far so good. Now comes release to PROD day....
I understand the the Power BI REST api allows for a PBIX to be uploaded in code. So I would anticipate the existing Powershell script would be built out to grab the PBIX from TFS and push it to a PROD Workspace, the CRM app config file would be set to include the new reports id, (Or retrieved from the DB) and the new page with embedded api/javascript code pushed out to PROD.
So, now all the bits would be there except the dataset.
How does that get to the prod environment?
Would there be any issues with the report ID once uploaded to the prod workspace etc?
Does anyone already do something similar, what is the best practice to adopt to facilitate a CI pipeline that uses Poer BI reports.
Hope someone can help
Gary
