It was so very tempting to use the title “Power BI Developer Mode is STILL coming” – this very promising feature has been a slow burner, having been originally announced back in June 2023. However, I was fortunate to attend a presentation at dataMinds Connect by Microsoft Programme Manager Rui Romano recently, where he demoed some upcoming features as well as sharing that General Availability for Developer Mode is due by the end of 2024.
So what does it actually mean? Historically, this much requested feature was referred to as “desktop hardening”. Historically a Power BI file would be stored with a .pbix extension. This file format essentially contained a huge binary file including the definition of the items data model and report. Technically it was actually possible to unzip this .pbix file and see that the .pbix was actually made up of a series of smaller files. If you wanted to, there were ways and means of “hacking” this content and making changes to those files directly, though this was an unsupported practice and developers would do so at their own risk.
Developer mode allows you to save your Power BI file as a .pbip format, also known as a Power BI Project. What this actually does is decompose the file into its constituent elements and save them in a folder. Changing these files with code editors now becomes a fully supported activity.
Being able to work with files at a more granular level presents several advantages.
Firstly, it makes source control far easier. The data stored within your file gets separated out as an analysis services backup file, meaning you can separate out the storage and only save the model and report definition in a git repository… if you’d tried saving a .pbix with a large data model in git previously you’d have to get in to the inconvenience of configuring large file storage in your git repos – this is no longer an issue.
It also makes tracking change across the Project easier in git. Models can be saved in the new TMDL format which creates an object per table in the model. Reports are broken down in to a folder structure with a folder per page that includes a folder per visual, with the visual definition itself kept in a .json specification.
Any changes made to the model can be tracked down to the line of code in the table, or a specific property in a specific visual. Being able to track this change (and roll back if need be) is incredibly powerful.
The fact that the Project format integrates so much better with git opens up opportunities for better change management as well as automated deployment and testing opportunities.
But the fun doesn’t stop there. Allowing access to edit files directly gives the opportunity to start working with content in a more programmatic fashion. When it comes to semantic model objects you can easily script elements or even copy and paste reusable definitions from other projects.
In many ways, this isn’t entirely new. At Advancing Analytics we’re big fans of Tabular Editor (TE) and you’ve been able to achieve this using their “Save To Folder” option for a long time. In fact the format TE decomposes the code to is at a lower granularity than that provided by a .pbip, which is arguably better. The C# scripting feature in TE also allows you to achieve a lot of automation for repetitive tasks. If you’re currently utilising Tabular Editor for semantic model development, I see no reason to change the way you work today.
However, if you’re not able to use Tabular Editor, developer mode opens up some great new possibilities for you. There’s a Visual Studio extension that can assist code editing for you, but Rui also gave a sneak peak of an upcoming new Power BI Desktop feature: a TMDL scripting view. This new feature hasn’t even made it to public preview yet, it was only available on a Microsoft internal build. It allowed you to interact with TMDL code without having to leave Power BI Desktop. There were some cool use cases for this, such as scripting out an existing object so you can add it to a different .pbip. Of course, the scripting view was also accompanied with a Copilot, allowing you to request changes to your model using natural language.
A cool example of this was seeing an entire model translated to a different language using the Power BI cultures feature.
The Copilot integration makes me a little nervous. Earlier in the day Kurt Buhler had already presented on some of the pitfalls of Copilot, specifically that the outputs are non-deterministic. The same prompts can potentially give you different answers. In comparison the C# scripting in Tabular Editor gives you very robust and repeatable automations. However, used wisely, I’m sure Copilot will prove useful.
Thus far it’s the semantic model development experience that’s received my attention, but where developer mode really does break new ground is that this code first development approach is now made possible for your visuals too.
At AA we’ve always been about applying good, robust and repeatable development practices to our work. The working practices of software engineering have gradually made their way into the lives of data engineers over several years, and our analytics practice has also tried to apply similar principles in our work too (hence our love of Tabular Editor and a code first approach to semantic model development).
Developer mode will now allow similar interactions with visuals. That could mean scripting out common report page layouts, or perhaps interrogating a page to make sure it meets best practice guidelines – Nat Van Gulck, an employee at Microsoft, has already been leading the way on this, with the development of his tool Power BI Inspector (GitHub - NatVanG/PBI-InspectorV2: A rules-based Power BI report layout testing tool.)
I can see a future where reports are created using the new .pbip format, saved to a git repository and deployed via CI/CD pipelines that include testing steps, much as we do with our semantic models today.
All of this promise comes with a health warning… the developer mode facility and the .pbip format are still preview features. In fact the development of the feature is perhaps a case study in why people shouldn’t become reliant on preview features, as so far the spec of the semantic model definition and the spec of the report definition have both gone through pretty drastic changes since the initial preview release. The recently released enhanced report format comes with a whole host of limitations that mean it's not currently fit for purpose in production environments. As such, we’ve so far held off implementing any of these development patterns with our customers. But it feels like general availability is just around the corner.
Another recurring theme coming out of dataMinds connect was leveraging Semantic Link for managing semantic models. The python library available in Fabric allows all sorts of automation possibilities – one great example was to detect downstream breaking changes and programmatically fix them using code. Imagine renaming a column in your semantic model breaking all the down stream reports, but then running a script that cycles through all of those reports and makes the fix for you. This is another fantastic tool to add to the advanced Power BI developers tool belt.
All of this contributes to the fact that the Power BI development experience is changing. There will always be a market for “clicky-clicky-draggy-droppy” approaches, but more and more developers at all stages of the analytics lifecycle are now starting to get the capability to really leverage code first approaches. These new capabilities will very likely see a step change in how organisations produce and manage their Power BI content going forward.
If you’re looking for assistance in how you can best approach your Power BI implementation, Advancing Analytics can help. Contact hello@advancinganalytics.co.uk to talk to our Analytics team today.