Microsoft Fabric Lifecycle Management: Getting started with development in isolation using a Private Workspace
When we talk about Microsoft Fabric workspace collaboration, a common scenario is developers and their teams using a shared workspace environment, which means they have access to “live items”. A change made directly within a workspace would override and affect all other developers or users utilizing that workspace. This is where git becomes increasingly important and there are two methods to follow as a best practice when developing for Microsoft Fabric. The first method is to develop in client tools such as Power BI Desktop to create semantic models or using VS Code to author Notebooks as an example. The second method is for developers who work within the Fabric service to utilize an isolated “private” workspace and commit changes to a shared environment. The second approach is what I plan to discuss in this article and provide how to get started if you want to use this method in your organization.
In this walkthrough, we’ll talk about how to set up git for a private workspace from a main branch, which is connected to a shared dev team workspace and then how to commit changes from the private workspace into the main branch of the shared workspace. It’s important to note that when you configure git at the workspace level, there can only be one branch connected to it at a time and can lead to questions on how to best collaborate. Before we progress further, there will be some assumptions that your Fabric prerequisites have been enabled to use git. These prerequisites can be found here.
Illustrated below is a high-level flow and diagram on how to use a private workspace for development in isolation with a shared workspace:
- Create a new workspace (or use an existing one you already use)
- Assign that workspace a Premium License
- Go to Git integration in the workspace settings, and specify the repo details
- Under Branch drop-down, choose create a new branch, and branch it from the main branch
- In the Git folder, enter the name of the folder you want to sync to your repo
- Save your changes and commit them into the feature branch
- When ready, create a PR to the main branch. The review and merge processes are done through Azure Repos based on the configuration your team defined for that repo
Let’s configure this in Fabric next, and see what it looks like:
I’ve created my private workspace, which I plan to use for isolated development, and I’ve made sure it’s connected to a capacity. This workspace is called DevelopmentWS and you’ll notice that as of right now, there are no Fabric items in it and no git repo has been connected to it under the Git Integration settings:
I need to connect the git repository and create a feature branch in my private workspace. The necessary details for this integration are sourced from the git repository connected to my dev team’s shared workspace, called FabricDEV. This workspace has been previously established and linked to a git repo within Azure DevOps and has Fabric items already synced:
Now, since I know the git configuration settings of the team’s shared dev workspace (FabricDEV), I can now configure the appropriate git settings within the private workspace (DevelopmentWS). Navigate to the DevelopmentWS git settings, input the Organization, Project, git repository and we’re going to go ahead and create a new feature branch:
You’ll get a new window that will ask for the feature branch name and where you want to create it from. I’m going to create this feature branch from the main branch of the shared dev team’s workspace:
This next step is important if you are using a folder location for Fabric Items, and you can see this path in your Azure DevOps repo. Before clicking connect and sync within the git integration workspace settings, you must provide the git folder path location of the main branch which contains the files for the Fabric items. Otherwise, your feature branch will be created without any Fabric Items to synchronize. Below is where you will get this folder location:
Your final git integration settings should look like this. We’ll want to click connect and sync at this point:
You’ll notice that the workspace begins to sync Fabric Items from the dev team’s shared workspace (FabricDEV) in the private workspace we created (DevelopmentWS):
Now, let’s compare the two workspaces and make sure we are in sync. The sync was successful and another thing to pay attention to is in the bottom left corner. Within the dev’s team shared workspace (FabricDEV) you will see the main branch connected and in the private workspace (DevelopmentWS) the feature branch is connected:
Now that we have our feature branch created from main, what if I want to make a feature change to an existing Semantic Model then merge it into main on the dev team’s shared workspace (FabricDEV)? Let’s do it! We can open our private workspace (DevelopmentWS) and look at the Semantic Model to add a measure. There is an important workspace setting we need to turn on to edit the Semantic Model within the Fabric service. It is under the Power BI General options and data model settings. Make sure this option is checked if you want to allow workspace members to edit data models in the service:
I’ve navigated to the Semantic Model in the Fabric Service and clicked on Open Data Model within my private workspace (DevelopmentWS). This will take you to the model view where we can add a new measure directly in the Fabric Service:
Please note: You may see a warning on the tables within the data model view saying it cannot retrieve field list. This is normal and the warning can be solved by just refreshing the Semantic Model.
I’ve added a new measure to the Semantic Model and next we can navigate to the Source control button within the service to commit the changes in the workspace:
Measure added:
I can see a Source control notification indicating the pending changes I’ve made in the private workspace (DevelopmentWS). At this point, you can either commit the change or there is an option to “undo” which will revert them. Let’s go ahead and commit:
Now, we need to issue a pull request within Azure DevOps to merge our changes into the main branch which is connected to the dev team’s shared workspace (FabricDEV):
While in the Pull requests UI, you’ll need to select the source and destination branch for this PR. Depending upon your organization’s policies and governance on lifecycle management for git operations, you can add your conventions to the Title, Description, Reviewers, Work Items and Tags:
The pull request has now been created. Let’s look at it and make sure there are no merge conflicts. Also, depending upon your organization’s final approval and completion policy, this is where you can set a certain number of approvers and track the history of your request. Let’s approve it and complete the pull request (I chose to delete this feature branch after merging into main):
With the pull request completed, we need to go back to the dev team’s workspace (FabricDEV). We’ll see within that workspace we have a pending update in the workspace, and we need to accept it:
Within the private workspace (DevelopmentWS), you should now see a notification now that the feature branch has been deleted and you need to connect a new branch. This is a recommended approach to delete the feature branch after it’s been merged and for future features that are implemented, create a new feature branch off of main from the dev team’s workspace:
Let’s check the our Semantic Model in the dev team’s workspace (FabricDEV). Our Semantic Model is synchronized and includes the changes we made to the model from the private workspace (DevelopmentWS):
Lastly, this is where deployment pipelines come into play. The dev team’s workspace (FabricDEV) can now use a deployment pipeline to push the feature across environments such as Test (UAT) and Production workspaces. If you’re new to deployment pipelines and looking for where to get started with those, please refer here.
Summary
To summarize this walkthrough, we went through a workflow for developing using feature branches within an isolated private workspace and synchronizing those changes to a dev team’s shared workspace. This is just one way to work with git and Fabric Lifecycle Management. Within your organization, there can be other ways in which teams collaborate, but hopefully this gives an idea of how developing in isolation using a private workspace can be used in and end to end shared workspace scenario.
Thank you for reading and I hope this helps with your Fabric journey!
References:
Overview of Fabric Git integration – Microsoft Fabric | Microsoft Learn
Git integration branches – Microsoft Fabric | Microsoft Learn
