In this writing, I aim to share my experience gained from my experimentation and investigation into the intricacies of operating Git integration within a workspace hosting two reports linked to the same semantic model.
In certain scenarios, Power BI developers opt to author a semantic model file and report file separately for enhanced efficiency and manageability. My exploration delves into the nuances of managing Git integration within such workspaces, elucidating the specific outcomes and appearances that transpire.
Given the presence of two reports in the workspace, two distinct Power BI files emerge within the Azure DevOps repository. I meticulously navigate through the process of committing changes to each file, providing a comprehensive portrayal of the resultant workspace appearance post-commit.
In my workspace called "Dev_workspace," here's how things are set up. I've also explained the lineage view below to help readers see how the two reports are connected to the same semantic model.
The workspace contains two reports, and they appear as follows.
I link the workspace with Azure DevOps, and the process is detailed as follows.
As anticipated, the display reveals one semantic model folder and two report folders, as illustrated below.
The term "Dataset" is still visible in this context. 😂
The steps below outline how to clone the repository from Azure DevOps to the local computer using VSCode.
Here, you can see one semantic model folder and two report folders, as depicted in the image below.
The following outlines my process of creating a .pbip file for each report by initially generating a .txt file and subsequently changing the extension to .pbip. It's important to note that this step is optional, and the Power BI file within each report folder (.pbir file) can also be utilized. This practice is my choice in working with .pbip files.
As two additional files are generated on the local computer, we can proceed to commit these changes to Azure DevOps. While these changes are reflected in Azure DevOps, it's essential to note that there will be no corresponding modifications in the Power BI workspace.
Now, let's explore the implications of fixing the sales .pbip file. I've modified two DAX measures, and since this alteration impacts the connected semantic model shared by two reports, it is expected that both reports in the workspace will be influenced by this change.
The following outlines the process of committing changes to Azure DevOps using VSCode.
As illustrated in the figure below, the commit changes are visible in Azure DevOps. However, upon inspecting the Power BI workspace, it indicates that there are no changes in the "QTY only" report. This is accurate, as the alterations involved two DAX measures that affect the semantic model but not the visualizations. While I'm not entirely certain about the reason for the "update required" message in the "Sales PBIX" report, my assumption is that the file itself has been fixed on the local computer.
As anticipated, the two reports in the workspace reflect the changes that were committed in the previous steps.
Let's proceed with changing the "QTY only" .pbip file on the local computer by modifying two DAX measures and one visualization. We'll observe the outcome of these changes.
As anticipated, Azure DevOps reflects the change commit. The workspace exhibits the modifications in the "QTY only" report and the semantic model, while there are no changes evident in the "Sales PBIX" report. However, given the correction to the DAX measure, "Profit = SUM ( Sales[Profit] ) * 7," it is reasonable to anticipate that the "Sales PBIX" report will also exhibit the corresponding changes. The absence of changes in the "Sales PBIX" report is attributed to modifications solely within the semantic model, without any alterations to the visualizations.
As depicted in the figure below, the "QTY only" report displays changes in both the DAX measure and the visualization. Additionally, the "Sales PBIX" report also reflects the modifications made to the DAX measure.
In wrapping up, delving into Git integration in a workspace with two reports linked to a shared semantic model has been quite revealing. Managing two reports tied to one semantic model brought out some interesting dynamics in version control. Through the step-by-step journey, it became clear that tweaks to the semantic model had a direct impact on both reports. This underscores how closely intertwined the workspace components are. Notably, when we tweaked DAX measures, it caused ripples, affecting the visualizations in turn.
This experiment taught me a lot about the interplay between Git integration and a shared semantic model. It emphasizes the need for a solid version control plan. While Git accurately tracked changes made through Azure DevOps, the Power BI workspace visually represented how these changes played out in each report.
In essence, this exploration serves as a practical guide for myself working in spaces with multiple reports connected to a shared semantic model. Knowing how changes flow through this system is key for keeping a smooth and efficient development process.
Comments