Since the launch of Microsoft Fabric, almost a year ago, Microsoft has been actively releasing new versions and feature updates on a regular basis, enhancing the tool’s capabilities and making it production-ready. At Eraneos, we are closely following the Microsoft Fabric Roadmap and regularly share some of the most important updates in our newsletters and through blog posts such as this one.
Git Integration and Improved Version Control
One of the most awaited features for those dealing with Power BI and Microsoft Fabric is Git integration and version control/historization. Power BI developers were always limited when working on the same report. They had to inform each other when one was finished making changes to the report, so another developer could pick up and continue working on the same Power BI report. Thus, the standard BI relationship between developers and reports was one-to-many, allowing one developer to work on one or more reports, whereas the reverse was not possible. This slowed down the development and delivery process and created dependencies on individual people.
Another well-known issue was tracking the reports version history as this was not available for users. Every user, depending on their level of technical understanding pursued various methods to tackle this. High-level Power BI users could track history of PBIX files either in SharePoint or OneDrive, which provides the possibility to view the version history of uploaded files. This method, however, was not perfect as the PBIX file is just a binary file and does not provide any information on the differences. More advanced users and developers, familiar with Tabular Editor and .bim files format, could extract the JSON-formatted BI models and track history of the model definitions by pushing them to Github or any other versioning platform. Nevertheless, there was no direct integration with Power BI Desktop and it was hard to understand all the changes for non-technical users.
To resolve these hurdles, Microsoft came up with an interesting solution. We will cover each point in detail:
- Power BI Project
- Git integration
- Azure DevOps integration
1. PowerBI Project
Power BI Project (PBIP) is a new file format introduced by Microsoft available in the newer versions of Power BI Desktop (June 2023 or later). Enabling PBIP, along with the older PBIX and PBIT file formats, allows you to save your Power BI reports as projects. PBIP creates separate folders for dataset and report definitions, which contain human-readable text files supporting text editor functionality, source control, and CI/CD. Additionally, Power BI also generates a .pbip file, which points to the respective report and dataset artifacts, and makes it possible to open Power BI reports on your desktop.
Apart from making changes in the PBIP report file, the same can be performed in the associated text files using other text editor tools, such as VS Code or Notepad. However, it has to be noted that there are dependencies between different Power BI artifacts, and altering specific definitions in one file can cause unexpected behavior/errors in others, resulting in PBIP files losing the link between each other and becoming useless.
While saving a report as PBIP file, the dataset folder stores multiple JSON files defining the dataset settings, configurations and metadata. Importantly, this folder also stores the model.bim file, which contains the semantic model of the dataset, and cache.abf, which caches data. Cache.abf is added to .gitignore by default as this is a common practice.
The report folder, stores JSON files containing report settings and configuration, as well as the report.json file that defines layout, visuals and interactions between them.
2. Git integration
Git is an open-source version control system that tracks versions of committed computer files and facilitates the development process for programmers and developers in terms of collaboration and fault-tolerance. Git allows to version your work, revert to previous versions, collaborate with other developers using Git branches, etc.
In order to work with Git within an Integrated Development Environment (IDE), such as Visual Studio Code (VS code), the former needs to be downloaded and set up in the IDE. Once the setup is complete, you can initialize a repository in VS Code by opening your local folder. From this point forward, all the changes made and saved in the PBIP file are tracked by Git.
3. Azure DevOps
Another component of Power BI & Git integration is its connection with Azure DevOps Services, a remote Git host. Azure DevOps repo can be seen as a remote copy of your local folder. Having created Azure DevOps organization and project and initializing a remote repository in VS code, you can now perform your initial commit and push the contents to the remote.
All the changes made to the PBIP in the local folder are now tracked in the source control. You can now stage the files for commit and push them to the remote repository. All versions committed to the branch are now tracked and can be reverted in case of report failure.
The last step is to synchronize the Fabric workspace with the Azure DevOps repo to have both-sided continuous integration workflow. The connection can be established using the Fabric workspace settings, which should automatically recognize the organization and projects created before in Azure DevOps. The synchronization will start copying the semantic model(s) and report(s) from the Azure DevOps repository into the Fabric workspace. From now on, whenever a change is made on one of the sides, Fabric will automatically recognize those changes and offer to update the report (in case the change is incoming from Azure DevOps) or commit to the remote repository (in case the change was firstly performed in the Power BI service).
It has to be noted that, currently, a Fabric workspace can only be linked with Azure DevOps and not with any other version control system.
TMSL vs TMDL
By default, when saving PBIX reports as PBIP, associated files are stored in the Tabular Model Scripting Language (TMSL) format. TMSL creates JSON-based scripts for both datasets and reports that were covered above. Compared to binary files that were not human-readable before, TMSL creates an opportunity to read and compare different versions of the report, see the differences between them. However, that process is not ideal yet. From my recent experience of comparing different versions of the same Power BI report and resolving merge conflicts, it gets really complicated to understand what is getting juxtaposed against what and which selection to make, especially if the report contains lots of dataset and report elements.
For that reason, the Microsoft Fabric team has recently added Tabular Model Definition Language (TMDL) format to Power BI. TMDL, which is currently in preview, is the successor of the well-known TMSL (Tabular Model Scripting Language). The new format allows for more human-friendly and easier YAML-like readability of semantic models. And, it really is! The text has become more structured and pleasant improving the source control experience. TMDL can be enabled in Power BI settings and will be applied on the next Power BI Project save. Similar improvements are also expected to be made for report objects readability and source control.
Conclusion
Having worked with Power BI & Git over the last couple of months, I must say that this relatively new feature is a game-changer. It has undoubtedly made the process of developing and publishing reports much safer as you can always revert to the previous version of the report. When it comes to multiple people working on the same report and merging branches, this is where the improvements are still to be made as reading JSON files is possible but not ideal. However, Microsoft is on its way to cracking this too with the feature updates for improved version control experience.
To conclude, as a BI developer, I must emphasize that Power BI & Git integration facilitates the day-to-day activities of report development. It makes the workflow process more collaborative, productive and less risky. Additionally, it also prompts me and other BI developers to learn and understand Git and the development lifecycle better.
Stay up to date!
Are you enjoying this content? Sign up for our (Dutch) Newsletter to get highlighted insights written by our experts.
