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.
Commit and push changes
Add bim-files to Azure DevOps
If we want to change the bim file, we need Tabular Editor. If you don’t have Tabular Editor yet, download this first.
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.