A Pipeline For PowerBI Embedded

June 24, 2020 Jared Porcenaluk

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 iss 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.

It is not always clear 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 (now known as 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 in order to deploy your PowerBI report alongside your code:

  • Create PBIX file using Microsoft PowerBI Desktop.
  • Upload the file to a development 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 the changes of others.
    • One workspace for all developers would be easier to set up (i.e. no need to plug in unique workspace info into the configuration file for each dev environment).
  • 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 configuration 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 New Signature. These are the types of challenges we face and overcome daily for our clients.

Previous Article
Office Explorers Podcast: Learn More About OneDrive with New Signature Experts
Office Explorers Podcast: Learn More About OneDrive with New Signature Experts

We are back with more from Kat and Rob. In this month’s New Signature- exclusive podcast they talk through ...

Next Article
Creating a Great Place to Work: Part II
Creating a Great Place to Work: Part II

In part one of this article, we reviewed a survey I held that established the following five things as attr...