Azure DevOps Power BI Integration

Purpose

This is a guide for setting up Power BI reports to be version controlled using Azure DevOps.

Prerequisites

You will need the access to the following services/programs:

• Power BI

• Azure DevOps

Why Azure DevOps

This process is useful for anyone looking to do version control outside of Power BI. Power BI does offer a native deployment pipeline process which can be used to version control, but it is significantly less flexible than Git. This is especially relevant when using a Snowflake data source, as Power BI Deployment Pipelines do not support Snowflake parameters, making it harder to use with multiple environments.

If you are interested in Power BI Deployment Pipelines still, please see the official documentation here.

1 Setting Up Power BI Git Integration

The first key change needed to transition to Azure DevOps version control is Power BI’s new(ish) preview feature called Power BI Projects. Power BI Projects (.pbip) files differ from Power BI Desktop files (.pbix) because they create artifact files that can be version controlled with a Git repo in Azure DevOps.

Open

1.1 Enabling Power BI Project Files

You can turn any existing .pbix file into a .pbip file by opening the file in Power BI Desktop.

1. Navigate to File > Options and Settings > Options. You should see a window open up.

2. Scroll down to Preview Features and click on it

3. Enable the “Power BI Project (.pbip) save option” checkbox and then press OK.

You should now be able to save any Power BI Desktop file as a .pbip file. When you do this, you will notice it creates other folders in your directory, called {Report Name}.Report and {Report Name}.Semantic Model . These folders contain a collection of JSON files and other files that contain information about the report. Anytime you make changes in the report and save it, these files will automatically be saved too.

1.2 Initialize Azure DevOps Repo

You’ll need to create an Azure project if you don’t already have one. After you’ve made a project, create an Azure Repo then clone it to your local machine. Add/save your .pbip files to the repo you just cloned. Make sure to move all the folders that came with the .pbip file as well, not just the .pbip report file by itself.

At this point I would recommend doing an initial push of the .pbip file(s) to Azure then use the GUI to initiate a pull request(s) to dev/test/prod. From there you can use your preferred Git interface as you normally would to pull/push branches from/to Azure. I have not run into any abnormalities here yet that make it any different from a normal Git workflow.

2 Connecting PBI Workspaces to Git

Once your Azure repo is setup, you’ll need to connect your Power BI workspace(s) to the repositories you created so Power BI knows where to look for reports and updates.

1. Open your workspace in Power BI. Click on Workspace Settings. Then navigate to Git Integration and you should see all of your Azure connections available through dropdown menus. This assumes you are logging into Azure and Power BI using the same account.

2. Select the correct branch, then connect it to your workspace. For example, if we are in a workspace called ws_ProjectName [dev], we will want to connect the dev branch we made earlier.

3. After exiting the settings, you will see a red notification on a button that says Source Control at the top of the workspace. Click on it and sync the changes from your branch to your workspace. You should now see any reports you had pushed to the branch in your workspace.

4. Repeat Step 2 with other workspaces. You will also need to sync the branch to the workspace every time you make a new commit to the branch, it will never sync automatically (as far as I know).

Note: It seems that in order to add/change the branch that is connected to the workspace, the user must be both an admin or owner of the workspace and be added to the Git repo in Azure. Needs further testing

2.1 How to Make a New Feature Branch

Let’s say you’ve been asked to make a new page for a report that multiple people are working on, so you create a new feature branch.

If you want to test your new feature branch in the Power BI Service before performing a pull request to dev, I would recommend creating your own “sandbox” workspace that you use exclusively for testing desktop reports in the service. For this workspace, naming conventions doesn’t really matter here, but mine is called ws_dev_braedenbailey . Connect your feature branch to this workspace and then sync your branch. You should now be able to view the report in the Power BI service.

The nice thing about this sandbox workspace is that since you (presumably) created and are the owner of it, you are free to change the branch connected to the workspace at any point and test the report. You can even switch to other feature branches or branches from other projects and just delete things from the workspace once you’re done with them. You can always retrieve a report as long as the branch exists by connecting to the branch and syncing again. Push your changes into dev once confident in the feature branch. This helps mitigate potentially confusing situations in the dev workspace.

4 Paginated Reports

Unexplored.

5 GitHub Version Control

Released silently by Microsoft in August 2024. Currently a WIP in exploring.