Power BI Desktop developer mode: source control for Power BI, finally

For as long as Power BI has existed, version control has meant a folder of PBIX files called something like "Sales_v7_final_FINAL". That is changing. Microsoft has announced the public preview of Power BI Desktop developer mode, and its first feature is the ability to save your work as a Power BI Project (PBIP).

A PBIP is not a binary file. It is a folder of plain text files that describe your report and your dataset. That one change is what makes Git, code review and automated deployments realistic for Power BI teams.

It was shown at Microsoft Build alongside Git integration in Microsoft Fabric. Here is what you get, how to start, and where the rough edges are.

What a Power BI Project is

When you save as a project, Power BI Desktop writes the report and the dataset as separate folders, each with text files that define the item. In the project root you will find:

• A <project name>.Dataset folder, which holds the files for the dataset, including model.bim.
• A <project name>.Report folder, where the most important file is report.json.
• A <project name>.pbip file, which is just a pointer to the report folder. Opening it opens the report and the model for authoring.
• A .gitignore file, so the local data cache (cache.abf) stays out of Git. Only metadata belongs in the repository.

The report and the dataset are independent in a project, just as publishing one PBIX gives you two items in the Service. The report finds its dataset through the definition.pbir file, and you can open a report from that file directly. Several reports and datasets can live in the same folder.

Why this matters

Text files open up four things:

1. Source control. You can track history, compare revisions, revert, branch and merge.
2. CI/CD. Changes can pass through quality gates, such as code review and automated tests, before they reach production.
3. Text editor support. VS Code for batch edits, with public JSON schemas for IntelliSense and validation.
4. Programmatic generation. Scripts can create or change item definitions.

After two decades in data, I have watched database code move into source control while BI stayed stuck with binary files. This is the first format from Power BI Desktop built for it.

How to get started

The feature is off by default. Go to File, Options and settings, Options, Preview features, and tick "Power BI Project (.pbip) save option". Then open a PBIX, choose File, Save As, and pick "Power BI project files (*.pbip)" as the file type.

Power BI Desktop has no built-in Git client, so you need another tool. The official walkthrough uses VS Code:

1. Open the project folder in VS Code.
2. In Source Control, select Initialize Repository and make an initial commit.
3. Keep working in Power BI Desktop. When you change a measure and save, the diff shows up in model.bim. A new report page shows up as a change in report.json.
4. When you are ready to work as a team, add a remote such as an Azure DevOps repo and publish the branch.

From there, Fabric Git integration closes the loop. A workspace admin connects a workspace to a branch in Azure Repos. Fabric then tracks differences, lets you commit workspace changes, update the workspace from new commits, undo back to the last commit, and check out a new branch. This first release supports datasets and reports. You can start in Desktop, continue in the Service and return to Desktop, with Git as the source of truth.

What still hurts

This is a preview, and it shows:

• Report editing is limited. During the preview, external changes to report.json are not supported. You can version the report, but you should not hand-edit it.
• The dataset is one big file. model.bim holds the model definition, so two developers changing different measures still touch the same file. Expect merge conflicts to need care. Microsoft says datasets will move to the Tabular Model Definition Language (TMDL) on the way to general availability, and reports will get a new, documented, source-control-friendly format.
• Git integration in Fabric only talks to Azure DevOps (Azure Repos) in this release. If your code lives on GitHub, the workspace sync is not for you yet, although local Git with PBIP works with any remote.
• Copying folders needs care. If you duplicate a report or dataset folder and use Fabric Git integration, you have to update the logicalId in the config file and the displayName in the metadata file yourself.
• Deployment APIs are still coming. Microsoft lists new Fabric REST APIs for deploying dataset and report definitions as future work, so fully scripted pipelines are not there yet.
• Your team has to learn Git. For many Power BI developers this is the real hurdle.

What to do next

I would not move a production team to PBIP this week, but I would start learning it now:

1. Turn on the preview option on your own machine.
2. Save a copy of one real report as a project and put it in a local Git repository.
3. Make a few typical changes (a measure, a relationship, a new page) and read the diffs. That tells you quickly what code review will look like.
4. If you have access to Fabric, connect a test workspace to an Azure Repos branch and try the round trip from Desktop to Service and back.
5. Write down what your team would need before adopting it: Git skills, branching rules, who merges what.

Takeaway

PBIP is Microsoft's first real answer to source control in Power BI. The preview is incomplete, especially on the report side, but the foundation is right: text files, Git and a path to CI/CD.

How are you versioning your Power BI work today, and what would it take for your team to switch?

Sources

• Deep dive into Power BI Desktop Developer Mode (Preview) (Power BI blog)
• Power BI June 2023 Feature Summary (Power BI blog)
• Introducing git integration in Microsoft Fabric for seamless source control management (Fabric blog)
• Power BI Desktop projects (Microsoft Learn)