Power BI release management

Organizations that start with Power BI often ask me "Jesse, how do you go about development, test and production environments when using Power BI?". I have decided to write about my experiences - I have been implementing Power BI since the beginning of the product - and share you my ideas.

The reason why this is a question to begin with, is because Power BI is partially a self service BI platform that also happens to be used for enterprise reporting and combinations of the two. You have your users who make their own models and do not rely on IT whatsoever. That form of self service BI does not really need DTAP (development, testing, acceptance and production) environments in my opinion. A self service user just wants to find the data (the real data, not test data), make a report and publish.

Corporate BI is the 'one version of the truth' data that must be governed and tested. The report on top of that might need to be governed too. So any changes to the model or the report (or both) need to go through some testing before it can be accepted. Hence DTAP & Power BI.

Let's explore a case where an organization has a HR department with a manager and a data analyst. Those two make the reports and decide what they want to publish to their target users: HR employees. A developer creates the datamart and the Analysis Services Tabular model cube on which they create Power BI reports. For the first version, they create a pbix file and upload it to Powerbi.com. What happens when the business wants the report or the model changed?

For this post I am choosing to skip acceptance, you can just apply what I write about test and create an extra environment.

1. Solution with two workspaces (IT managed reports)

So now we have 3 environments: a development, test and production server with SQL data marts and Analysis Services. There is a test workspace in powerbi.com and a production workspace that is published as a Power BI app. The business report authors, in this case the HR manager and the data analyst have access to the workspaces. The target audience has only access through the app. The developer works with Power BI desktop and syncs the changes with source control, in this case TFS. The reports are only consumed through the app.

In this scenario, if the business wants to change the report without needing to change the data model in AS, they do so in the test workspace. If the user is happy with the new version, they ask IT to deploy it to production and update the app. IT will download the report from test workspace, sync it with TFS, change the connection string to the production cube and publish the report to the production workspace.

If the data model needs to be updated as well then IT will first download the latest version from test workspace (the business might have pending changes that otherwise may be lost), deploy the cube changes to the test cube, change the report and publish it to the test workspace. If the business is happy with the changes then both the report and the cube will be deployed to production.

Pros:

  1. Your report has version history;
  2. Reports can be rolled back if the users break the report;
  3. Any change is monitored and tested.

Cons:

  1. The business cannot easily change the reports on the fly quickly because every change has to be tested;
  2. You need IT for every change.

2. Solution with one workspace (hybrid self service BI)

Another way to go about it is to see powerbi.com as the production platform. The users can directly change the report in the workspace and deploy the changes to the app themselves. The only time you need IT is when the cube needs to be changed. IT deploys the new cube to test, downloads the latest version of the report from the production workspace, changes the connection string to the test cube and shows it to the users. If they like the changes then the cube is updated and the report is published to powerbi.com. Do make sure the business does not alter the report in the meantime as those changes will be lost.

In this scenario it is good to realize that the workspace, even though it is placed within the production area of the image, kind of functions as 'development' for the business users! They can change the report as they see fit in the workspace, and deploy those changes to the app where it is consumed by the target audience.

pros:

  1. Users can change the reports whenever they want;
  2. Easy to explain to business: change report in workspace, happy? then update the app;
  3. Cleaner and clearer management of workspaces;
  4. Faster delivery to target audience.

Cons:

  1. If the business can change the report by themselves then those changes might not go to version control in TFS;
  2. If the users break the report in the workspace then there is no rollback (!).

Conclusion

If you have enterprise mission critital reports then you will prefer the first solution with two workspaces. You can rollback and every change is tested even though it is a small report change.

If you have more flexibility and you want to allow the users more power, you can go the hybrid self service way where they can alter the report themselves and publish the app when ready.

Obviously you should decide for your business what the best way is to deploy your reports. Do you have different ideas? Share them with me in the comment section!

Principal BI consultant at Rubicon

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

2 Comments

    • Jesse Gorter

      Jesse Gorter

      that looks pretty good, would make deployment much easier

Next ArticleDimensional modeling in 2018