In this writing, I like to share what I have tested when version controlling in Power BI with Azure DevOps.
Recently, I could experience how much efficient and effective the version control is with Git Integration in Power BI Workspace. And I wanted to step further and learn more about it. The first thing that came up to me was how can I go back to the previous version, and what will happen if I did three commits but reverted the second commit.
Firstly, I like to share how I do one commit and how I revert the last commit.
In PBIP file, create two new visualizations like below.
Commit the change is VS Code. And Git Graph in VS Code shows like below.
After synchronizing, Azure DevOps shows the change like below, and Power BI Workspace also shows the change.
However, if your team does not like the two visuals that are added to the report, you can decide to revert the last change in Azure DevOps.
In the below, you can choose an option other than "Merge (no fast forward)", and the diagram appears to briefly explain how the branch will change.
After synchronizing Power BI workspace, the report will show no visuals that are created in the last commit.
But, how about the PBIP file stored on the local computer?
On the local computer, VS Code still shows the last commit which is "Add two visualizations".
However, after synchronizing with Azure DevOps, it shows what happened in Azure DevOps (reverts the last commit).
And magically, when you open PBIP file, it shows no visuals.
This makes all three areas, Power BI Workspace | Azure DevOps | Local PBIP file, show the same.
Secondly, I will do three commits and revert the second commit, and let's find out what happens.
My assumption is, the first and the third commit still remain but only the second commit will be undone.
First commit: Add a DAX measure.
Second commit: Fix the DAX measure that is added in the first commit.
Third commit: create a visualization with the DAX measure.
First commit: add a new DAX measure = [Top one customer measure:]
Second commit: fix the DAX measure
Third commit: add a visualization using the new measure.
All are synchronized to show changes in Azure DevOps and Power BI Workspace.
Revert the second commit.
All steps about how to revert are already described above so I skip those.
Once the revert is finished, the below diagram is shown.
In Power BI Workspace, there is one notice that indicates only the dataset is changed that needs to be updated. This means that the new visualization that is added in the third commit will remain.
As a result, the DAX measure without the KEEPFILTERS function in the visualization is shown below.
And, after synchronizing in VS Code, the PBIP file in the local computer also shows the visualization without the KEEPFILTERS function.
To summarize, if there are no conflicts, the commit that you revert only is applied, and the rest of the commits still remain without any changes. If you have the first commit | second commit | third commit, and if you revert the second commit, the first and the third still remain in the PBI report.
And I need to consider and come up with a decision about how small the commit I should make.
Every line change in the DAX formula should be one commit?
Or, the changes in one DAX formula should be one commit?
Or, one visualization should be one commit?
I totally agree with the saying, "If you commit big, you have to undo big". And my homework is to define how much workload is the optimal size of each commit.
I hope this helps to have more fun in playing with Azure DevOps and VS Code for Power BI Version Controlling.
Comments