One of the biggest challenges in Microsoft Fabric today is the one branch per workspace limitation, which makes it difficult to work on multiple feature branches simultaneously without creating separate workspaces. To address this, I propose Fabric Desktop, a local development environment that allows users to build and test Fabric artifacts offline before syncing changes to a workspace.
Fabric Desktop could function similarly to Power BI Desktop but for Fabric, enabling users to develop lakehouses, dataflows, pipelines, and notebooks locally while integrating seamlessly with version control. This would provide a true branching experience, where multiple developers can work on different features without conflicting changes in a shared workspace. It would also improve offline development, reduce the risk of unintended modifications in production workspaces, and offer faster iteration cycles.
whos with me to upvote this one!?
2 Comments
Even if a full local integrated experience is developed, just adjusting the scope on existing tools could be a great improvement:
- VSCode Fabric Engineering extension has it's own publishing mechanism to sync with the workspace, and notebook files that are stored as folders. Why not use standard notebooks and store connection information to the proper lakehouse within those as a parameterized value.
- There is no warehouse artifact as part of that fabric engineering extension. If you connect to the git repository you see the sqlproj file and the individual sql files, but they are all marked as autogenerated and read only so they are not usable through GIT.
- No other artifacts are available: EventHouses, Reflex... we just see some json files, in some instances empty ones.
Interestingly most of the functionality to use this codebase from local environments should already be available: sql scripts, python scripts, tmdl files, notebooks, airflow jobs... Server components are also available: spark sessions, synapse connections... These should all be first level citizens in the fabric environment and cloud editors could be built to work with them. Instead, it seems like the cloud editor is developed first and as such everything is made into json for the editor. That leaves existing tools: vscode, copilot, git as an afterthought when, for engineering work, they are the real backbone.
No scalable and performing engineering work takes place in no-code platforms.
As we look at moving on-prem workflows into Fabric we are hit time and again by these limitations that impact not only our progress but also developer productivity and satisfaction.
