Git and workspace strategies for your Microsoft Fabric development process

[KevinChant]

In this post I want to share some advice about Git and workspace strategies for your Microsoft Fabric development process.

To be more precise, advice about aligning with a DevOps way of working for with branches, Microsoft Fabric Git integration and Fabric workspaces when multiple developers need to work in isolation before updating what is seen as the "development branch". Like in the below diagram.

Microsoft Fabric development process when working with Git

Thanks to the introduction of Microsoft Fabric Git integration there are now various ways to work with feature branches and isolated workspaces. In order to align with DevOps practices implemented over the years. Working with these feature branches provides a good foundation for your CI/CD method of choice.

I decided to write this post because I recently I received some questions relating to this. Note that I coined the term isolated workspaces instead of feature workspaces in the above diagram. I show why in this post.

To help with some terminology, branches allow you to work with your code in a new area within the same Git repository. Which looks and feels like an entirely new copy of your work. Typically, you make changes in one branch and then merge those changes into another.

In reality, the Git repository does not make a full copy of your work in a new branch. Instead branches and changes are managed by a hidden Git database. You can read more about this in the Branches in a Nutshell document.

Advice about Git and workspace strategies for Microsoft Fabric

I decided to split this section to highlight two distinct types of workspaces that you can apply when working with Microsoft Fabric Git integration.

Feature workspaces

By far, this is the most well-known option and is the one highlighted in the recommended development process by Microsoft. 

This is where you branch-out from a development workspace that is connected to a development branch to a short-term feature workspace connected to a feature branch. Once you have completed your work you then synchronize your changes back to the development branch and workspace. Like in the below diagram.

Working with feature workspaces

Microsoft has fantastic documentation that covers how to branch out to new workspace when working in a Microsoft fabric workspace. Which can be found in the article on how to manage branches in Microsoft Fabric workspaces.

To align with common DevOps practices, the feature branches and workspaces should only exist for the lifetime of the work performed for the feature. Once done, the changes should be synchronized back to the development branch and the feature branch and workspace removed.

Personally, I think branch out to new feature workspace with the GUI is the best scenario because it can work to scale. However, even though this is the most popular option, there are a lot of environments that do not allow developers to create their own workspaces.

One workaround for this is to implement a level of automation that first creates the feature workspaces and branches and then configures the Microsoft Fabric Git integration between the two. Which is ideal when the users do not have enough permissions or when you need to do this on a very regular basis.

One example of how to automate the above is with the custom “Branch Out to New Workspace” that can be found in in the Fabric Toolbox GitHub repository. Another alternative is dedicated developer workspaces, which I cover next.

Developer workspaces

If your developers work with a short number of features or you want to avoid workspace sprawl caused by too many feature workspaces another option you can implement is developer workspaces. Where you have a dedicated workspace for each developer and constantly create new branches that are connected to that workspace. As per the below diagram.

Working with developer workspaces

In this scenario, the branches should ideally have a short lifespan and the workspaces for as long as the developer is involved with the project(s). Another key point to remember is that this does require branches to be cleaned up afterwards. Something that you can look to automate.

To avoid feature branch sprawl you can reuse the same branches per developer workspace and keep synchronizing them with the development branch. Which is ideal in situations where the automation involved relies on a constant branch name.

Just bear in mind you will need to continuously synchronize the branches in question. Plus, ensure the developer workspaces are connected to the correct feature branches. Because this scenario is the one has the highest chance of causing merge issues.

Branch lifespan

Whichever type of workspace you decide to work with you should aim to have branch lifespans as short as possible. Just like when working with any other DevOps related solutions. Like in the below diagram.Working with branches with short lifespans

When working in an Agile related way the lifespan is typically one iteration/sprint. Which is usually when a specific feature is expected to be delivered. However, this can vary.

One key point to remember is that the longer your branch exists the higher the chance that you will need to sync it with the development branch. In order to avoid conflicts with other feature/developer workspaces involved.

Another point to stress is that you should remove your feature branches once you have finished with them.

Final words

I hope that this post has given you food for thought about Git and workspace strategies for your Microsoft Fabric development process.

Once you have a good foundation in-place you can look to improve your Continuous Integration maturity level by implementing automated tests. Which you can configure to take place when somebody tries to update the development branch from the feature branch.

Feel free to share your thoughts about any topic mentioned in this post.