Deploying changes from one workspace to another space - Using DevOps

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

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)