PowerBI has a lot of power, no pun intended. Created primarily as a self-reporting tool to be used by the C-level suite as well as managers, it has grown and matured to the point where it’s edging out SSRS in capabilities. In fact, you can now embed PowerBI into end-user applications (“App Owns Data” as they call this scenario, where users see data your app owns) via Power BI embedded.

One story that isn’t so clear is how to develop and release PowerBI reports alongside the code of an application. Sure, one could embed a report, and publish updates to it via the PowerBI Desktop application, but who is testing these reports? Who is managing report changes that affect the code? If you take advantage of the PowerBI Embedded JavaScript SDK to create custom buttons to update the report filters, for example, you’d likely want to see those changes to the code happen at the same time as changes to the report.

This problem has a fairly clear story when it comes to using Microsoft tools for DevOps: VSTS/TFS Build & Release (well, now, DevOps Pipelines). In the video above, I discuss the steps to deploying a PowerBI .pbix file along with your code.

These are the basic steps to take to deploy your PowerBI report alongside your code:

  • Create PBIX file using Microsoft PowerBI Desktop.
  • Upload the file to a dev PowerBI workspace to see changes in the application when developing locally.
    • This could be one PowerBI workspace for all developers, or once workspace per developer.
    • One workspace per developer would allow for everyone to work completely isolated from changes of others.
    • One workspace for all developers would be easier to set up (no need to plug in unique workspace info into the configuration file for each dev).
  • Include the PBIX file in the source control.
  • Use a VSTS build task to include the PBIX file in the artifacts to be released.
  • Use the PowerBI Actions task from the Visual Studio Marketplace to release to different environments.
  • Include your environment details in config variables that are replaced when releasing to different environments.
  • Store passwords in a secrets file (locally to the developer) when developing locally, and in VSTS as a secret variable for different environments.
    • Of course, this is not as secure as storing the credentials in something like Azure Key Vault. Look into this for any somewhat serious application.

The trick is to treat the .pbix file like any other piece of code! Good luck out there, and if you’d like help with this sort of thing, don’t hesitate to reach out to us. This is the sort of thing we do for a living, after all.