You can consider this post a Fabricators guide to version control in Microsoft Fabric. Including my unique insights and how this ties in with Microsoft’s latest document relating to CI/CD workflow options in Fabric.
To be more specific, I intend to go into a lot of detail about Microsoft Fabric Git integration in this post.
Which is the unified version control solution offered in Microsoft Fabric. As opposed to the separate methods of version control that you can look to implement for some individual Microsoft Fabric items.
In this post I provide insights about various topics relating to Microsoft Fabric Git integration. Ranging from the initial setup to working with APIs.
Plus, the content can help those that studying for either the DP-600 exam or the DP-700 exam. Along the way I share plenty of links.
If you need help with any jargon used in this post, then I recommend that you read one my other posts. Which is a Microsoft Fabric Git integration jargon guide for Fabricators.
Version control references in the DP-600 and DP-700 exams
One of the reasons I decided to include version control as part of the title for this post was to make it easier to find for those studying for either of the Microsoft Fabric exams. Plus, it makes it easier to find for those new to Microsoft Fabric as well.
In my previous post about the DP-600 exam updates I highlighted the fact that the skills measured for analytics development lifecycle has barely changed. Which includes knowing how to configure version control for a Microsoft Fabric workspace.
Whereas the DP-700 exam requires knowledge about implementing lifecycle management in Microsoft Fabric. Which includes knowing how to configure version control.
One thing I want to highlight about the DP-700 exam is that you can book to take the beta version now. Those looking to take the DP-700 beta exam can prepare yourselves now with my checklist for the DP-700 beta exam.
Uniformed version control in Microsoft Fabric
As I mentioned earlier in this post, you can implement version control independently for the metadata of Power BI reports, semantic models and Data Warehouses.
However, there is an official way to perform uniformed version control in Microsoft Fabric. Which is by implementing Microsoft Fabric Git integration.
Microsoft Fabric Git integration allows you to create a connection between a Microsoft Fabric workspace and a Git repository. To be more accurate, a branch within a Git repository.
When implemented the metadata (code) for supported items are synchronized between the workspace and the branch in the Git repository.
Like in the below example. Which shows how a Git repository in GitHub looks when synchronized with a workspace that contains Fabric items.
Be aware that there are varying levels of support for supported items. For example, a database project is created behind the scenes for a Data Warehouse. However, for a Lakehouse all you get is a container that contains the Lakehouse name.
Microsoft Fabric Git integration allows you to work with various features typically associated with version control to manage the stored metadata. Including committing changes and undo’s within Microsoft Fabric itself.
Plus, the ability to work with all the features of Git to manage the Git repository behind the scenes.
Configuring Microsoft Fabric Git integration
When Microsoft Fabric Git integration was first made available it only supported Git repositories stored within the Azure Repos service in the cloud-based version of Azure DevOps.
However, recently support has been added for repositories stored in the cloud-based version of GitHub.
Microsoft does a good job in documenting how to get started with Git integration. Including how to connect a workspace to a Git repo. Which details their approach to do this to connect to a repository in either Azure DevOps or GitHub.
Because the configuration of Git integration varies depending on whether you configure Azure DevOps or GitHub. However, whichever one you choose the source control features within Microsoft Fabric work the same.
Below is a diagram that highlights the differences when configuring for either Git provider.
As you can see in the previous diagram, the main difference is that you configure Azure DevOps with the Microsoft Entra user account you are currently logged into Microsoft Fabric as. Whereas, to configure GitHub you need to create a personal access token.
To clarify, currently you need to enter the repository URL twice during the process of configuring GitHub. I did not add it twice in the previous diagram by accident.
Selecting GitHub as a provider
One visible difference when you use GitHub as a Git provider is when you configure a new GitHub account. Due to the fact that the connection details are stored in Microsoft Fabric.
You can view the created connection accounts by going to the “Manage Connections and Gateways” section in Microsoft Fabric. I covered some implications relating to this in my post about security considerations when using GitHub with Microsoft Fabric Git integration.
In addition, my other blog post that covers choosing Azure DevOps or GitHub for Microsoft Fabric Git integration.
Branching to new workspace
Once Git integration is enabled a new “Source control” button appears in your workspace. Microsoft details what you can do when you select this button in their getting started with Git integration article. However, I do want to highlight some key points in this section.
First of all, changes done directly in the workspace appear in the “Changes” tab in source control. Whereas when you perform updates directly in the Git repository the updates are shown in the “Updates” tab.
Secondly, I want to highlight the ability to branch to a new workspace. Since it is a newish capability.
When this feature is selected it allows you to create a new workspace which is connected to a new branch in the same Git repository. In addition, it automatically synchronizes all supported Microsoft Fabric Git integration items into the new workspace.
It will only synchronize a copy of supported Microsoft Fabric Git integration items into the new workspace. Which means that at this moment in time Fabric items like Dataflow Gen2 will not be synchronized into the new workspace.
However, if the source workspace does contain a Dataflow Gen2 item it will attempt to synchronize any staging items which are invisible in the original workspace. Such as a staging Lakehouse and/or Warehouse.
These staging items will be visible in the synchronized workspace. So, bear that in mind.
I must point out here that deleting any Dataflow Gen2 items directly in a workspace that has Microsoft Fabric Git integration configured also has an interesting side effect.
Because deleting the Dataflows Gen2 item alone can cause any underlying staging objects created for it to start appearing in your workspace. Which means you must consider how to remove these additional items.
Anyway, branching to a new workspace provides you with a quick way to start working in an isolated environment. Which is covered in Microsoft’s recent article about suggested CI/CD workflow options.
Version control in relation to Microsoft’s CI/CD workflow options
Recently Microsoft released an article with their advice on how to choose the best Fabric CI/CD workflow for you.
Within their article they state that the development process should be the same for all of the suggested deployment scenarios in that article. Their suggestion is to work in an isolated environment to work on a specific feature. Which can be either of the below.
- A separate Microsoft Fabric workspace connected to a feature branch for a specific repository.
- Alternatively, somebody working with an IDE on their local machine where they work with a clone(copy) of the Git repository locally that has a feature branch. For example, working with a Power BI Desktop project in Power BI Desktop.
Microsoft recommends in their article that once done you then merge your updates with the feature branch in the remote repository stored in either Azure DevOps or GitHub. From there, merge the update(s) with next branch you intend to use.
You can visualize this in the below diagram.
Depending on which Fabric items you are working with I propose you that you take it a step further. By introducing Continuous Integration in the form of unit tests when you go to merge the updates from the feature branch to the destination branch.
Doing the testing early in the process is also known as “shift-left testing” or “shifting left”. Which is a good DevOps practice.
I based the previous diagram on working with Power BI reports. However, you can perform unit tests with a variety of Fabric items supported by Microsoft Fabric Git integration. Including Data Pipelines.
You can view various unit testing options in another post of mine. Where I cover various options to perform unit tests on Microsoft Fabric items.
Viewing version control changes locally
You can view Microsoft Fabric Git integration changes locally by cloning (copying) the Git repository from your source system to your local machine.
From there, you can view the commit history with the application of your choice. Either through a command line or a nice GUI interface.
For example, when you are working in Visual Studio Code you can now view the history of commits in the source control section. Which shows a friendly source control graph.
Git APIs
Finally, I want to highlight the fact that you can manage Microsoft Fabric Git integration through a set of Git APIs. Which allows you to perform various tasks remotely. For example, you can call an API to connect a workspace to a git repository and branch.
Microsoft published a post earlier this year that introduced how you can automate your CI/CD pipelines with Microsoft Fabric Git REST APIs. Including a link to the PowerShell examples.
When looking to work with a Microsoft Fabric Git API make sure you check the level of identity support for it. In addition, check that it supports your chosen Git provider.
Final words about version control in Microsoft Fabric
I do hope that this Fabricators guide to version control in Microsoft Fabric proves to be insightful.
Because the aim of this post was to provide further insights. As well covering knowledge that can be helpful for both the DP-600 and DP-700 exams.
Of course, if you have any comments or queries about this post feel free to reach out to me.
This is a great article, Kevin. It’s really helpful to see you clearly explain how to set up version control this way as an option for Fabric and Power BI developers.
[…] recommends that you first implement the development process that I highlighted In my previous post about version control to populate a workspace that represents the development […]