Power BI version control with Azure DevOps

During the development of BI-solutions most of the sources are well maintained: central source location, version control, tracking changes, and automated deployment. Yes, not everything. Most of the time data pipelines, database(s), and analysis service model(s) are controlled with a service like Azure DevOps. Power BI models and reports are often not controlled centrally. There are many reasons why and I did it too. But since I found out how easy it is to integrate your Power BI development process with Azure DevOps, I never create Power BI reports without Azure DevOps anymore.

Power BI Premium licenses give you some extra features like deployment pipelines. That’s great, but for many organizations, a premium license is like buying a Ferrari when you need a bicycle. So, in this blog series of 4 posts, I’ll show you how you can improve your Power BI development process big time with just some small steps using Azure DevOps. And you only need a Power BI pro license.

In this first blog post, we’ll see how Power BI reports can be added to Azure DevOps so, we’ve decent version control of these files. We’ll look at both pbix-files and bim-files.

Add pbix-files to Azure DevOps

In Azure DevOps, we can just add files alongside Visual Studio projects. So, assuming you have a project for your database and/or analysis service, we’ll add another folder where the Power BI-files are added. Why? To keep all your development – including reports – together in one solution.

Setup

In Visual Studio I have a solution for a database project. On the same level as the project folder, I created a new folder called ‘Power BI Files’. I added the pbix-files here. The solution is linked to the ‘Shop Sales App’-repository and de main branch. My solution looks like this:

Note: You can add these files within another project (e.g.; the database project). But the reports are a different part of the whole solution so, I’ll put them within the same solution but separate from all other projects. Also, you typically use multiple branches during development but that’s for another blog post.

You typically use multiple branches during development but that’s for another blog post.

Now, let’s check out Azure DevOps. You can find the same repository, branch, and pbix-files here.

Commit and push changes

When you make changes to the reports, you need to work from the pbix-files from your local repo folder. In my case ‘C:\Users\hylke\source\repos\Shop Sales App\Website\Power BI Files‘.

I made a change to the file ‘Reporting Sales.pbix’ and I saved the file. Visual Studio immediately notices the change that is made. Check out the red mark on the left of the Power BI file.

Now, I want to commit and push my changes to our central repository in Azure DevOps. To do so, click the ‘Git Changes’-tab, next to the ‘Solution Explorer’-tab. If this tab is not visible, you can click go to the menu and click View –> Git Changes.

On this tab, you see that the pbix-file is the list with changes.

With the Git Changes-tab opened, add a comment. Click the arrow on the right of Commit All and click Commit All and Push.

When we go back to Azure DevOps, the pushed changes are visible.

Note: It’s overwriting the pbix-file. No merge and no way to check the differences. So, be careful when developing together with others.

Note: Adding PBIX-files with the datamodel (import mode), your saving data to Azure DevOps. This might be against governance rules.

Add bim-files to Azure DevOps

The way you add bim-files to Azure DevOps is pretty much the same as pbix-files. The big difference is what you can do with the files in Azure DevOps. Because a bim-file has a JSON-format we can see what has changed! This is only relevant for Power BI files which contain a data model.

If we want to change the bim file, we need Tabular Editor. If you don’t have Tabular Editor yet, download this first.

Open your Power BI data model file and let’s open Tabular Editor from Power BI Desktop.

We’ll make a change here and save the changes to a bim file. I’ll hide the ‘description’ column from the ‘Product Group’-table.

You need to save your changes to the bim file from your local repo folder. In my case ‘C:\Users\hylke\source\repos\Shop Sales App\Website\Power BI Files‘.

After the change, you’ll notice the red check in Visual Studio again.

Commit and push changes as described above in the PBIX paragraph. When we check Azure DevOps we’ll see that the changes are available in Azure DevOps.

Now we can click on the bim file and go to compare. You can see all the differences between the new and old version(s).

So, it works, but you have a bit of extra work to accomplish the advantage of tracking changes in the data model.

Note: You can also merge changes made in different bim-files. Even though it’s technically possible, I wouldn’t advise you. A bim-file is a single file with a lot of ‘code’ that has a lot of dependencies. You have a big change of complex merge conflicts which are easier to solve by making one of the two changes again. So, in your development process make sure only one person at the time makes changes to the bim-file and pushes this to Azure DevOps.

Conclusion

Adding Power BI files to your Azure DevOps environment is a good way to start improving your Power BI development process. It’s easy to implement and it gives you a decent way of source- and version control.

As you’ve seen, you can create bim-files and deploy them to Azure DevOps to monitor changes to the data model. This can be useful when you need the ability to go back in time with the data model only (e.g. disaster recovery). In most other use cases, you can use the PBIX file with the data model.