Collaborative Power BI development with pbip

For many years, having several developers work on the same Power BI report was challenging to say the least. Merging multiple reports into a unique one often gave headaches to Power BI report developers. Tools like AML Toolkit existed to merge semantic model changes (tables, columns, measures, etc.) but even with such tools, the task remained painful. In addition, nothing existed for the visual part of the report.

All of this was before the .pbip format entered the room! Let’s see how multiple Power BI report developers can collaborate on the same report with that new format.

If you’re discovering the .pbip format, I suggest you read my previous blog on the topic: Power BI git CI/CD and git integration.

Context

Ok, so I’ve got a very simple Power BI report that has been published to a workspace in a Fabric Capacity. The report is made up of a simple Product dimension and a Sales fact table. The report has a single page called First Page. The workspace is linked to the main branch of an Azure DevOps repo.

Here’s what we want to do. A tech lead called dev0 has two developers in his team, dev1 and dev2 who both need to make changes to that report.

Dev1 needs to add a Date dimension and a line chart to First Page to display Sales Amount per month
Dev2 needs to add a new measure and a new visual to First Page to display overall Sales Amount and Quantity

Let’s see how these two developers can collaborate and do these tasks simultaneously!

Dev1 updates

Dev1 has some work to do. He knows that dev2 also has some work to do on the same report so he has to make his changes using the git integration provided by the .pbip format. He can’t use the Power BI Desktop publish button.

So there he goes:

He clones the remote Azure DevOps repo to his local machine using VS Code
He creates a branch called dev1/add_date_dimension_and_line_chart from the main branch
He opens the .pbip (or .pbir) file from his local repo
He adds a Dates dimension
He adds a line chart to the First Page page

Note: for a reminder on how all of these steps are done, check my previous blog post on the topic

Here’s what First Page looks like when he’s done.

He saves his updates and goes back to VS Code to push his changes to Azure DevOps. He creates his pull request between his feature branch and main and waits for tech lead dev0 to review it.

We see that 3 files were impacted by dev1 changes.

diagramLayout.json is just the model view from Power BI Desktop; since we added a Date table, the model view was logically updated
model.bim was impacted since we added new tables and columns to the semantic model
report.json was impacted because we made visual changes; it’s quite hard to have a clear understanding of the updates we did just by looking at the json code for now

Dev 2 updates

Just like dev1, dev2 is going to perform some updates on the report using the .pbip format.

She clones the remote Azure DevOps repo to her local machine using VS Code
She creates a branch called dev2/add_measure_and_cards from the main branch; note that at this point the main branch does not yet contain dev1 updates as the pull request was not completed
She opens the .pbip (or .pbir) file from her local repo; again notice that she doesn’t see dev1 updates in Power BI Desktop
She adds a Total Quantity measure
She adds two cards to First Page

Here’s what First Page looks like when she’s finished.

She saves her updates and goes back to VS Code to push her changes to Azure DevOps. She creates her pull request between her feature branch and main and waits for tech lead dev0 to review it.

Dev0 synchronization

Ok so dev1 and dev2 have both pushed their changes to DevOps and are waiting for tech lead dev0 to review their changes. He looks satisfied by dev1 updates and approves his pull request. Dev1 then completes his pull request at which point his changes are now in the main branch. Yay!

Dev0 then has a look at dev2’s pull request and looks satisifed as well. He approves the pull request. Dev2 then tries to complete the pull request but oh no, our worst git enemy: conflicts!

Note: you may not see the Conflicts tab on your pull request. This tab is added by an Azure DevOps extension that allows you to handle such situations. Check Install extensions and Pull Request Merge Conflict Extension in order to install the extension.

We’re going to have to solve that conflict on the report.json file for dev2 to be able to push her updates. To do so, I’m using the extension mentionned just above but other tools exist to do so as well.

Head over to the Conflict tab. We see the two versions of the file that generated the conflict at the top. At the bottow, this is where we’re supposed to handle the conflict (i.e. indicate which part from which version we wish to keep).

Honestly, it was still a bit painful to solve that conflict, even when the report and updates were so simple. The report.json file is still hard to work with at the moment.

Keep in mind however that we forced a conflict here by modifying the same report page and even the same object on that page. If each developer had been working on his own page, we would not have had any issue. Notice for that matter that no conflict was generated on the model.bim file even though both developers modified it.

Still, after handling the conflict, dev2 is able to complete the pull request.

At this point, anyone with access to the Power BI workspace can just go and synchronize the workspace. Notice that we do that manually here, but APIs were recently released to do so, I’ll show in a future blog post how to use these APIs so no manual action is involved.

After synchronization, here’s what the report published to the service looks like. Tada!

Conclusion

Power BI reports and semantic model can now benefit from collaborative development thanks to the new .pbip format and Fabric git integration. Some things can still be made easier, especially when working with the visual aspect of the report and the report.json file but things are very promising overall.

Thanks for reading!