Forum Discussion
Deploying changes from one workspace to another space - Using DevOps
Hello
I need some guideance on smth.
Current setup is like this:
- Using Synapse analytis to extractr data from Oracle OCI and using Data Lake /csv format, transform using DaTa flows and use Azure sql db as DWH.
- Using Power BI to build reports.
- Not yet migrated to Fabric but that's the next step.
We are looking at slowly moving to Fabric and using Fabric Capacity for some reports which are .txt file and need to be uploaded to the Bank Regulator of the country.
What I am trying in azure fabric is:
- Load few tables from DWH (Azure sql db) and create Lakehouse tables. I am using Copy Job for this to copy data from azure sql db to fabric lakehouse. Using Dev workspace.
- Then I use NoteBooks to transform these data and produce txt files in daily and monthly basis which need to be uploaded to a portal which is National bank of the country.
- In fabric we generate some banks statements as well.
- Many other Reports which are created in PowerBi created by connecting to Azure SQL db (DWH) are moved from one workspace (DEV, UAT and PROd) by using Deployment Pipelines and this is good enough for now.
Now since I have other scripts/pipelines/ Notebooks developed in fabric I want to do the same thing.
Move all these into different workspaces now from Dev to UAT and Prod.
I want to DevOps which I we are using for Synapse deployments but in fabric I need the whole flow and what's the practise to deploy things from one workspace to another workspace.
Other questions are:
- Do I need to create Lakhouses prior on each workspace (UAT and Prod) and give them the same name I take it?
- How about the connections to Azure sql db DWH (do I have to create them) for each env pior in fabric or in the deployment I configure them automatically?
Any advise please!
Thanks
Xhev
Hi XhevahirMehalla,
Hope you're doing well!
--> SITUATION :
Your setup makes complete sense, and the good news is that what you're trying to do is absolutely achievable. You're essentially running two parallel worlds right now, your proven Synapse + Azure SQL DWH stack, and a new Fabric layer on top of it for regulatory outputs and Lakehouse-based processing. The deployment challenge you're facing is real, but well-solved once you understand how Fabric's Git integration works alongside Azure DevOps.
The core principle to internalize: Power BI reports move via Deployment Pipelines (which you already do well), but Fabric engineering assets / Notebooks, Copy Jobs, Data Pipelines, Lakehouses / move via Git integration tied to Azure DevOps. These are two separate tracks, and trying to force one tool to do both jobs is where most teams get stuck. Your Two Deployment Tracks
Track What it covers Right toolPower BI Reports, Semantic Models Deployment Pipelines ✅ keep as-is Fabric Engineering Notebooks, Copy Jobs, Pipelines, Lakehouses Git + Azure DevOps Setting Up Git-Based Deployment
Connect each workspace to a dedicated branch in your Azure DevOps repo via Workspace Settings → Git Integration. A clean branching model looks like this:
- dev branch → syncs with Dev workspace
- uat branch → syncs with UAT workspace
- main branch → syncs with Prod workspace
Developers work in Dev, commit through the Fabric UI, raise a Pull Request to uat, and your Azure DevOps pipeline calls the Fabric REST API (updateFromGit) to push it across. Prod requires a manual approval gate on the pipeline before anything touches it.
--> What Git actually saves from your fabric workspace :
Notebooks, Data Pipelines, Copy Jobs, and Semantic Models all get committed as files. Lakehouse metadata gets captured too. What does not travel through Git: the actual data in OneLake, and crucially, connections and credentials. Those are always environment specific by design.
--> QUESTION 1: Do you need to pre-create Lakehouses in UAT and Prod?
Yes. Create them once manually with the exact same name as in Dev. Fabric will match by name on deployment and wire everything up correctly. You only do this once per environment, after that, Git handles everything.
--> QUESTION 2: Do you need to create Azure SQL DB connections per environment?
Yes, and this is intentional. Never hardcode connection strings in Notebooks. Instead, parameterise your Notebooks so a Pipeline can pass the right server and database name at runtime depending on which workspace it's running in. Pre-create named connections in each workspace pointing to the right database (Dev DB, UAT DB, Prod DB) with consistent logical names. Fabric then resolves the right connection at runtime.
--> Remember that :
Parameterise any OneLake paths in your Notebooks, they are workspace-specific and will break if hardcoded. Use a Service Principal (not a personal token) for your DevOps pipeline to call the Fabric REST APIs in production. And always validate in UAT that deployed items actually run, not just that they deployed without errors. Fabric's Git integration is still maturing, particularly around Copy Jobs.
Finally, that's the full picture. Git integration is your source of truth for logic and structure; connections, credentials, and data are infrastructure you manage per environment. Once that mental model clicks, the rest follows naturally.
Hope this helps. Feel free to ask me questions if needed, and don’t forget to Accept as Solution if this guidance worked for you. That's motivate me to keep helping.
Best regards,
Oussama (Data Consultant & Fabric's Expert)
4 Replies
Thank you for reaching out to the Microsoft Fabric Forum Community.
Tamanchu oussamahaimoud Thanks for the inputs.
I hope the information provided by users was helpful. If you still have questions, please don't hesitate to reach out to the community.
Hope everything’s going smoothly on your end. I wanted to check if the issue got sorted. if you have any other issues please reach community.
Hi XhevahirMehalla,
Honestly, your approach already sounds very reasonable and actually quite aligned with how many enterprises are gradually moving from Synapse to Fabric today.
Keeping :
- a dedicated DEV workspace
- separate UAT / PROD workspaces
- and introducing Fabric progressively
is definitely the right reflex.
For your scenario, Fabric currently gives you two main deployment approaches depending on how far you want to go with automation.
1. Start with Deployment Pipelines (good starting point)
For many teams beginning their Fabric journey, Deployment Pipelines are usually the easiest and safest first step.
They work well for promoting most core Fabric items such as : Lakehouses, notebooks, pipelines, semantic models, dataflows
The setup is fairly straightforward :
- create a Dev - UAT - Prod pipeline
- assign the workspaces
- deploy between stages from the UI
So for a first Fabric rollout, this is honestly a good and pragmatic approach.
2. Yes, create separate Lakehouses per environment
I would strongly recommend separate Lakehouses for DEV /UAT /PROD
Usually : same structure, similar naming convention, but physically separated environments
Example :
- lh_regulatory_dev
- lh_regulatory_uat
- lh_regulatory_prod
That separation becomes very important later for : testing, governance, rollback, security, data isolation
3. Connections and environment parameters
This is one area where Fabric still requires some care.
Connections to : Azure SQL DB, Oracle, external storage, gateways are usually environment specific.
So yes, in practice you will often need, separate connections, separate credentials and sometimes separate bindings per environment.
What helps a lot is externalizing, server names, database names, workspace IDs, paths into :
- notebook parameters
- config files
- variable libraries
instead of hardcoding them directly in notebooks. Deployment Pipelines can also help override some values per environment.
4. Git / Azure DevOps later (recommended as maturity grows)
Deployment Pipelines are great to start. But once the platform grows, most teams eventually combine :
- Git integration
- Azure DevOps or GitHub Actions
- Deployment Pipelines
Because they solve different problems :
- Git, source control / collaboration / branching
- Deployment Pipelines, promotion between environments
So your Synapse DevOps experience will definitely help later in Fabric too.
5. One important recommendation
I would test the full DEV - UAT - PROD promotion cycle very early, especially for :
- Notebook dependencies
- Lakehouse bindings
- SQL connections
- Credentials
- Pipelines
because some Fabric items still have evolving CI/CD behavior compared to mature Synapse deployments.
Better to validate the deployment mechanics early before scaling the platform.
Useful docs:
- https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines
- https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/deploy-content
- https://learn.microsoft.com/en-us/fabric/cicd/git-integration/intro-to-git-integration
- https://learn.microsoft.com/en-us/fabric/cicd/variable-library/variable-library-overview
Hope this helps clarify the deployment path a bit 🙂
You’re already asking the right architectural questions early, and honestly that’s usually what makes Fabric migrations much smoother later on.Feel free to share how you finally structure the DEV/UAT/PROD flow this is a very relevant topic for teams coming from Synapse.
Hi XhevahirMehalla,
Hope you're doing well!
--> SITUATION :
Your setup makes complete sense, and the good news is that what you're trying to do is absolutely achievable. You're essentially running two parallel worlds right now, your proven Synapse + Azure SQL DWH stack, and a new Fabric layer on top of it for regulatory outputs and Lakehouse-based processing. The deployment challenge you're facing is real, but well-solved once you understand how Fabric's Git integration works alongside Azure DevOps.
The core principle to internalize: Power BI reports move via Deployment Pipelines (which you already do well), but Fabric engineering assets / Notebooks, Copy Jobs, Data Pipelines, Lakehouses / move via Git integration tied to Azure DevOps. These are two separate tracks, and trying to force one tool to do both jobs is where most teams get stuck. Your Two Deployment Tracks
Track What it covers Right toolPower BI Reports, Semantic Models Deployment Pipelines ✅ keep as-is Fabric Engineering Notebooks, Copy Jobs, Pipelines, Lakehouses Git + Azure DevOps Setting Up Git-Based Deployment
Connect each workspace to a dedicated branch in your Azure DevOps repo via Workspace Settings → Git Integration. A clean branching model looks like this:
- dev branch → syncs with Dev workspace
- uat branch → syncs with UAT workspace
- main branch → syncs with Prod workspace
Developers work in Dev, commit through the Fabric UI, raise a Pull Request to uat, and your Azure DevOps pipeline calls the Fabric REST API (updateFromGit) to push it across. Prod requires a manual approval gate on the pipeline before anything touches it.
--> What Git actually saves from your fabric workspace :
Notebooks, Data Pipelines, Copy Jobs, and Semantic Models all get committed as files. Lakehouse metadata gets captured too. What does not travel through Git: the actual data in OneLake, and crucially, connections and credentials. Those are always environment specific by design.
--> QUESTION 1: Do you need to pre-create Lakehouses in UAT and Prod?
Yes. Create them once manually with the exact same name as in Dev. Fabric will match by name on deployment and wire everything up correctly. You only do this once per environment, after that, Git handles everything.
--> QUESTION 2: Do you need to create Azure SQL DB connections per environment?
Yes, and this is intentional. Never hardcode connection strings in Notebooks. Instead, parameterise your Notebooks so a Pipeline can pass the right server and database name at runtime depending on which workspace it's running in. Pre-create named connections in each workspace pointing to the right database (Dev DB, UAT DB, Prod DB) with consistent logical names. Fabric then resolves the right connection at runtime.
--> Remember that :
Parameterise any OneLake paths in your Notebooks, they are workspace-specific and will break if hardcoded. Use a Service Principal (not a personal token) for your DevOps pipeline to call the Fabric REST APIs in production. And always validate in UAT that deployed items actually run, not just that they deployed without errors. Fabric's Git integration is still maturing, particularly around Copy Jobs.
Finally, that's the full picture. Git integration is your source of truth for logic and structure; connections, credentials, and data are infrastructure you manage per environment. Once that mental model clicks, the rest follows naturally.
Hope this helps. Feel free to ask me questions if needed, and don’t forget to Accept as Solution if this guidance worked for you. That's motivate me to keep helping.
Best regards,
Oussama (Data Consultant & Fabric's Expert)
