Forum Discussion
fabric git with vs code
Hi safrasmusthafa ,
Thanks for the follow up and thanks svenchio for providing your valuable guidance on this.
Below is some more detail on the pattern that was mentioned, since there is no native way to block direct publish from VS Code when a user has edit access to a Fabric workspace.
The main idea is to separate development work from controlled deployment.
You can create one or more Git enabled dev or sandbox workspaces. In these workspaces, developers have full edit access. They can create Fabric items such as notebooks, pipelines, lakehouses, and warehouses using VS Code or the Fabric portal, and then push their changes to feature branches in Git or Azure DevOps. These workspaces are used only for development and are not meant for production.
In parallel, you maintain a single integration or production workspace. In this workspace, regular users do not have edit access. This prevents direct changes from VS Code, the portal, or APIs.
Updates to the integration workspace happen only through Git integration. Usually, this workspace is linked to a protected branch like main, and updates are done using UpdateFromGit, either by a small set of admins or through automation using a service principal.
With this setup, developers can work freely, but the controlled workspace can only be updated through Git.
svenchio , please confirm if this matches what you meant, or add any corrections or extra details if needed.
Hope this helps, please reach out for further assistance.
Thank you.
safrasmusthafa if you are looking for an ON/OFF switch wthin your VS Code extension titled "Only push to code" or in Fabric, sorry to inform, there's No such thing, fruthermore, the “publish” action from VS Code is just a call to the same Fabric APIs the web UI uses. If a user has edit rights on the workspace, they can write from any client (portal, VS Code, REST, etc.) and Git integration tenant settings only control whether users can sync workspace ↔ Git, not whether they can edit the workspace itself.
There's however, another similar solution ... use Git-enabled sanboxes for your developers to interact with Fabric freely (Creating items and pushing the final version to feature branches) and have one Integration workspace RESTRICTED to be able to create items from long-live branches (e.g. main) and automate the UpdateFromGit with code using a service principal, so, this way, you funnel your developement and prevent unaccounted/unexpected changes on the workspace you're trying to have close control off and at the same time allowing developers to do their job! How's that sound as an alternative? I can share a bit more on this if interested... meanwhile, hope you find this info useful and would appreciate a thumbs-up. Best of lucks!
hi thanks for reply, yes please share more details.
Hi safrasmusthafa ,
Thanks for the follow up and thanks svenchio for providing your valuable guidance on this.
Below is some more detail on the pattern that was mentioned, since there is no native way to block direct publish from VS Code when a user has edit access to a Fabric workspace.
The main idea is to separate development work from controlled deployment.
You can create one or more Git enabled dev or sandbox workspaces. In these workspaces, developers have full edit access. They can create Fabric items such as notebooks, pipelines, lakehouses, and warehouses using VS Code or the Fabric portal, and then push their changes to feature branches in Git or Azure DevOps. These workspaces are used only for development and are not meant for production.
In parallel, you maintain a single integration or production workspace. In this workspace, regular users do not have edit access. This prevents direct changes from VS Code, the portal, or APIs.
Updates to the integration workspace happen only through Git integration. Usually, this workspace is linked to a protected branch like main, and updates are done using UpdateFromGit, either by a small set of admins or through automation using a service principal.
With this setup, developers can work freely, but the controlled workspace can only be updated through Git.
svenchio , please confirm if this matches what you meant, or add any corrections or extra details if needed.
Hope this helps, please reach out for further assistance.
Thank you.Thanks v-veshwara-msft for further explaining the idea and yes, your description captures quit nicely my original proposal and I'm so glad our collague safrasmusthafa is interested in know more about this 😊 because I can share some code that it might help you... A LOT 🤞😁
As I explained on my new article series CI/CD workflow for Fabric & Power BI fully automated! (Series) , MSFT suggests various workflows, from option #3, in a nutshell, I explain the idea.
In my article series, I'm going deep-dive on this pattern, including the code to make it happend, it include the logic to perform the updateFromGit operation, connect with SPN via Azure DevOps connection and more... check also the youtube video I prepared showing a demo of the whole solution working ... I'll posting complementary articles and video with additional info.
CI/CD workflow for Power BI reports fully automated! (Series) - YouTube
Uff the will be lot of information, I'm confident you will something useful 😅🤞 .... hey, a kudos would be nice of course and even better, accept this one as a solution.
