Do you work with Power BI? Then you probably recognize the following scenario; you are working on an existing report in Power BI Desktop and have a nice new version ready for publication. But, without you realizing it, a colleague was also working on the same report and saves his version over your version. The result: your changes are undone, so you have to start all over again. In this blog, technical consultant Joep Hermans shares how to prevent this scenario from happening again and how to apply version control.  

'The last publish wins'

The above approach is incompatible with the principles of CI/CD. Simply because it can lead to great frustrations the moment you work with different developers in the same Power BI environment. To use all the functionality of Power BI, you have to develop locally with Power BI Desktop. In this process, each report is stored in a separate file. In this file format, the report definition and the data on which the report ran were fixed. As a result, files with large data sets quickly took up a lot of space. When you were satisfied with the final result of your report and dataset, you could save your file locally and publish it to the Power BI Service. If you wanted to tinker with an existing report at that point, you could do two things. One edit the local file and hope it was the latest version or two generate a file based on what was the current version in the Service at that time. In this way, Microsoft offered no way to keep version history of reports. With as long the principle of "the last publish wins" at the time of simultaneous work on the same report. 

The solution

Developers came up with all kinds of workarounds to prevent "the last publish wins. The simplest way is to keep version control in the naming of your files by giving them a date or version number. However, this relies heavily on agreements you make with each other and proper compliance. Since nothing is enforced by the system. The danger is that things get mixed up and versions are lost. In short, you have to take too many things into account and really keep a close eye on what you are doing.  

A decent version control setup makes these problems disappear at once. You want to be able to see what has been changed to a report at any given time. Where you can always go back to previous versions for each report. When working simultaneously on the same report, you also want to be sure that the different changes are compatible in a new version. So your Power BI environment benefits enormously from good CI/CD functionality. 

The advantage of Power BI version control 

In early 2024, for the first time, the preview finally included an option to save files in PBIP format from now on, which stands for Power BI Project. This includes the option to pull data definition from report definition and save it in a separate TMDL format file, which stands for Tabular Model Definition Language. This simplifies a way of working where you can reuse data sets and where data can be seen separately from the report. This is a concept that had been around in the Service for a while. Locally, however, data and report definition were always inextricably linked. Unlike the old PBIX file format, both file formats now include a structure that allows files to be attached to a git repository. In that git repository, two separate folders can now be created. One for data definitions (TMDL files) and one for report definitions (PBIP files). These files can then be checked in and out as usual. You can also work in different branches, using a pull-request to check whether certain changes fit into your branch and the branch you want to merge into. When working on the same files simultaneously and both versions are pushed to the git repository, this can potentially lead to merge conflicts, where you can specify which version to keep for each file. Following this principle, of course, it is also common to keep a development and a production branch and occasionally do a release from one branch to the other. 

 If you are connected to a centralized git repository, you can link the Power BI Service to it as well. After this, you can then start linking workspaces to branches in the Service, giving you different versions for each workspace. The moment changes outside the Service are detected, you will be notified and it will be possible to pull them into the Service as well. Once you have a development version, a test version and a production version for each workspace, you can connect these workspaces together. And the change process can be orchestrated using the so-called deployment pipelines. When building these pipelines, you can define certain rules for each environment. So that the changes you make in your development workspace are properly propagated to the test workspace and later to the production workspace.  

Note that the moment a report and dataset move to the next branch, the dataset needs a refresh to show the correct data in the report. So it sets up a new empty version of the report and dataset definitions, so to speak. 

The main disadvantage of git integration within Power BI is that it is only available for workspaces that have premium or fabric capacity. Thus, Power BI Pro workspaces do not have git integration. In principle, it would be possible to fabricate your own custom solution using the PBIP files. However, this is a lot less end-user-friendly than facilitating it in Power BI itself. It also takes you more time to implement and then manage this. 

Future

Version control is an important step in professionalizing Power BI as a development tool. Not only does it make it easier to develop things, but more importantly it contributes to the stability of your environment. This radiates more professionalism to the end user. Whereas Microsoft used to focus strongly on self-service with Power BI, they are now playing catch-up in terms of structurally building the development environment. A good setup of version control is an indispensable link in this. Despite the fact that there are still some snags in the current implementation, it is a great relief that this functionality has now been implemented.