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.
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.
