Initial Microsoft Fabric Git integration tests for Power BI Reports

Reading Time: 8 minutes

In this post I want to share the results of some of my initial Microsoft Fabric Git integration tests for Power BI reports. Based on tests that I performed in the public preview version of Microsoft Fabric.

I have been very keen to do these tests. Due to my background with CI/CD, including the GitHub repositories that I share. Such as the one you can use as a template to perform CI/CD for Microsoft Fabric Data Warehouses using Azure DevOps.

To manage expectations, this post covers:

1. Brief overview of Microsoft Fabric Git integration.
2. How I converted a Power BI report to a Power BI Desktop project containing metadata files.
3. Converting the folder that contains the Desktop project into a Git repository.
4. Synchronizing the Git repository with Azure DevOps.
5. Setting up Microsoft Fabric Git integration.
6. Initial tests.
7. Interesting workaround to deploy a second Power BI report using metadata.

In addition, this post contains plenty of links.

To follow along with this post you can read my other post that covers how to create your own Microsoft Fabric environment. Which includes how to setup both Microsoft Fabric and Azure DevOps.

One key point to note is that Microsoft Fabric is now generally available. You can read more about this in detail in the official post by Ryan Majidimehr.

Overview of Microsoft Fabric Git integration

Just to clarify, Microsoft Fabric Git integration allows you to synchronize supported items in a Microsoft Fabric workspace with a Git repository stored in Azure DevOps.

Which gives you the flexibility to work with various items in multiple workspaces and opens up some interesting options.

For example, the code for a Power BI report along with a dataset can be stored in a Git repository and synchronized with one or more workspaces. Like in the below diagram.

Note that in the above diagram the arrows go both ways. To highlight that changes can be bi-directional.

To manage expectations, this post only covers deploying to a single Microsoft Fabric workspace. If you are keen to deploy to multiple workspaces I recommend my other post about working with Microsoft Fabric Git integration and multiple workspaces.

At this moment in time, the supported items for Microsoft Fabric Git integration are Lakehouses, notebooks, reports, paginated reports and semantic models(datasets).

Examples in this post

For this post I used my own Microsoft Fabric public preview environment which contains a new workspace. In addition, an Azure DevOps organization that I created in the same environment.

Plus, I have the latest versions of Power BI Desktop and Visual Studio Code installed. I use Visual Studio Code as a Git client. You are free to use another one of your choice.

In addition, I used the same Git repository that I created for my post. Which covers how to prepare Azure DevOps for Microsoft Fabric Git integration.

As for the report, well I happen to have one from my previous post.

New Power BI project

Now there are many variations of the order of initial steps below. For example, I could initialize the new Git repository in Azure Repos. However, to follow the flow in the diagram earlier in this post I will start with creating the report first.

To prepare my Power BI report for this post I enabled the ‘Power BI Project (.pbip) save’ option in Power BI Desktop. Which is covered in ‘Enable preview features‘ section of the Power BI Desktop projects documentation.

I then went to save the existing report as a project by selecting the ‘Power BI project files’ type.

Tip: I strongly advise you save your project files in brand new folder. In order to keep them all together and everything neat and tidy. It would be nice if Power BI Desktop had an option to do create the project in a new folder.

Once done I went into Visual Studio Code and opened up the folder that I created which contains the Power BI Desktop project files. I expanded the folder view by one level below so that you can get an idea of what files are there.

Anyway, to make this folder a local Git repository I went into source control in Visual Studio Code and selected ‘Initialize Repository’. I then did an initial commit of all the files to the Git repository by adding a message and clicking the blue ‘Commit’ button.

To help with some jargon, a commit is basically a hard save to the Git repository. Behind the scenes the commit is logged in a hidden ‘.git’ folder within the repository.

Synchronize local repository with Azure DevOps

I was then ready to synchronize this repository with my new one in Azure DevOps. Again, there are many ways to do this.

One way is to get the path to the new repository in Azure DevOps as below and add it as a remote using the Visual Studio Code menu.

Alternatively, you can open up a terminal in Visual Studio Code and copy the two lines that are in the “Push an existing repository from command line”. Which to me seems more graceful. However, you miss the full menu experience.

Anyway, once done I clicked refresh on the empty repository in Azure DevOps and it showed objects.

So, I went into my workspace in Microsoft Fabric and opened up workspace settings to configure Git integration.

Whenever I configure Git integration with a service like Azure Synapse Analytics, I tend to setup a subfolder. Which you can do in workspace settings by adding a folder name in ‘Git folder’.

Plus, I tend to add another branch. However, for my initial testing I set it to the main branch and left the folder option empty as you can see above.

Initial Microsoft Fabric Git integration tests

Finally, I was ready to do some testing. First, I tested disconnecting the workspace and then reconnecting the workspace.

You disconnect the workspace from the Git repository by going into workspace settings again and clicking the ‘Disconnect’ button. From there I selected the first sync option.

That worked fine. However, I had not changed anything. So, with Git integration running I decided to add a description to my Power BI report within Microsoft Fabric.

Straight away the Source control button flagged up within my workspace in Microsoft Fabric. To show that a change had occurred.

So, I went into Source control and committed the change.

Note, if you sync your workspace with Git like I did above then I strongly recommend that you sync any clones (copies) of the repositories that are elsewhere when possible. To avoid any conflicts

For example, when using Visual Studio Code, you can do this easily do this by selecting to synchronize changes. Which you can do a few different ways in Visual Studio Code.

Including clicking the synchronize changes icon in the bottom left-hand corner of the window next to the branch name.

Change in the Git repository

Next, I decided to test making a change in the Git repository. To keep a nice natural flow, I opened up my local clone (copy) of the Power BI project in Power BI Desktop.

From there I changed the name of one of my pages to ‘Completed Backlog items’. I then saved the project and went into Visual Studio Code. Which recognized the change to my local Git repository.

I then committed the changed and synchronized my local clone with the one in Azure DevOps.

How did Fabric react to this? Well, I first had to refresh the page to get the below reaction to appear.

However, once done it did give me a nice message to inform me that I had unsynced commits from Git. So, I clicked on Source control and selected ‘Update all’.

Note that this time clicking ‘Source control’ took me to the ‘Updates’ section. Anyway, this test also worked fine.

More interesting Microsoft Fabric Git integration tests

After doing the above standard tests I decided to try some more interesting scenarios.

I first tested changing the description for the report locally. By editing the ‘item.metadata.json’ file in the ‘Azure DevOps example. Report’ subfolder.

After the change I synchronized it with Azure DevOps and then I was able to synchronize it within Microsoft Fabric.

I then decided to test what would happen if I disconnected the workspace first and then changed the description in Microsoft Fabric. That worked fine as well.

So, I decided to do the above test again, except this time select to select the ‘Sync content from Git into this workspace’ option. Which also worked.

Creating second Power BI report for Microsoft Fabric with metadata

I then decided to test the boundaries a bit further by copying the ‘Azure DevOps example.Report’ folder to create a copy of the report.

It was at this stage that I started experiencing issues with Microsoft Fabric.

When testing adding a new report through metadata, I began to get ominous error messages like the one below.

To cut a long story short, to create a duplicate report using metadata I had to do the following:

1. Make a copy of the folder containing the existing report and rename the folder.
2. In the new folder, remove the ‘.pbi’ subfolder.
3. Edit the ‘item.metadata.json’ file in the new folder to change the ‘displayName’ value.
4. Copy the ‘logicalId’ value from the ‘item.config.json’ file in the original report folder and increase the last numerical value by one in the same file in the new report folder.
5. Commit the changes and synchronize the repository with Azure DevOps.

Once done I had created a new report in Microsoft Fabric using Visual Studio Code.

In reality, I do not recommend doing this. If you read the specification for the item.config file you can see that the logicalId value is a required value. Manually increasing it by one not only makes it unsupported but also makes me nervous.

My advice is to stick to creating copies of reports in Microsoft Fabric or look to implement a more graceful method.

Final words about initial Microsoft Fabric Git integration tests for Power BI Reports

I hope me sharing my initial Microsoft Fabric Git integration tests for Power BI Reports within a public preview environment has made for an interesting read.

My first impression of working with it in public preview is that it works well providing you use it as intended.

Of course, if you have any comments or queries about this post feel free to reach out to me.