u/darshan-thakur

We're trying to move off doing everything manually in the browser and actually get a proper dev/test/prod setup going for our Fabric workspace.

the git integration part was fine, connected the workspace to a repo, branching works, that side makes sense.

where it's falling apart is the actual promotion between stages. Notebooks and Spark job definitions move through the deployment pipeline cleanly. Anything with a connection string or workspace specific parameter doesn't carry over the way I expected, so after every deploy I'm going in by hand and fixing things that should've just mapped over.

it Feels like I'm missing a step around parameterization, like there's supposed to be a config file or rule set that handles this per environment, but the docs just kind of gloss over it and jump straight to "click deploy."

Also not clear on where connection strings for dev vs prod should even live. In the pipeline itself, in a variable library, somewhere else entirely?

Is this actually just manual cleanup every time for people, or is there a proper pattern for this that I'm not seeing?

Been doing most of my Fabric notebook and Spark job work through the browser UI for months, finally tried wiring things up through VS Code last week since the team kept asking why we weren't doing this already. Wanted to share some real takeaways since most posts I found were either too basic or just extension docs rephrased.

Once it's connected it actually works really well. Real intellisense, proper git diffs on notebooks instead of staring at JSON blobs, multi-file editing, all the stuff you'd expect from a real IDE. Switching between notebooks and feeling like you're actually coding instead of clicking through cells is a genuine upgrade.

Honest thing nobody really tells you though, not every item type plays nice. Notebooks and Spark job definitions work great. Pipelines and dataflows basically don't show up as editable files, so this isn't a full replacement for the workspace UI, more like a better editor for the code heavy stuff.

Also the auth setup is a bit finicky if your VS Code account doesn't already match your Fabric tenant. Honestly just easier to sign out and back in cleanly through the right Entra account before connecting anything.

One thing to check before you even start, make sure your Azure DevOps org or repo is connected to the same Entra ID tenant as your Fabric capacity, otherwise the extension just sits there showing nothing. wasted like 20 mins thinking it was a permissions issue.

overall it's not perfect yet but for anyone doing serious notebook development in Fabric this is a proper quality of life upgrade compared to the browser editor.

has anyone gotten pipeline or dataflow editing working through any workaround, or is everyone just bouncing back to the browser for those too?

So I've been meaning to do this for a while and last week I actually sat down and connected my Fabric workspace to Azure DevOps for proper Git integration. wanted to share some real takeaways since most posts I found were either too basic or just Microsoft docs rephrased.

Once its set up it actually works really well. being able to commit changes to notebooks, semantic models and dataflows directly from the workspace UI without switching to VS Code or doing anything manual is genuinely useful. branching works, commit history works, you can see exactly what changed between versions which is something I really missed before.

Honest thing nobody really tells you though, not everything in your workspace is supported yet. lakehouses for example dont sync the actual data, only the metadata and schema. took me a bit to figure out why my lakehouse wasnt showing what I expected after a pull lol

Also the initial branch setup is a bit finicky if your Azure DevOps repo already has existing files in it. honestly just easier to start with a clean repo and let Fabric populate it from scratch.

One thing to check before you even start, make sure Git integration is enabled at the tenant admin level first otherwise you wont even see the option anywhere. also your Azure DevOps org needs to be connected to the same Entra ID tenant as your Fabric capacity, wasted like 20 mins figuring that one out

overall its not perfect yet but for teams doing any serious development work in Fabric this is a proper game changer compared to manually exporting and reimporting items every time something changes.

has anyone tried this with GitHub instead of Azure DevOps? curious how the experience compares

Hey everyone

So I've been trying to manage my Fabric workspace items directly from VS Code instead of jumping back and forth to the browser UI all the time and honestly its a bit confusing still lol

currently I am working with notebooks and semantic models mostly, trying to figure out a clean way to sync things without breaking stuff

is anyone else doing this? would love to know how others are handling it like are you using the Fabric extension or doing it manually through the API?

just looking for people to discuss and maybe share workflows, still learning so any tips are welcome!

Been doing Fabric implementations for a while now so I went through the Build announcements with that lens. A lot of noise but two things genuinely matter for anyone working in Fabric day to day.

Fabric IQ and Work IQ APIs are the ones to watch

The Work IQ APIs go live June 16 with programmatic access to emails, documents, meetings and org data. The reason this matters practically is that most Fabric-based agent projects I have worked on hit the same wall — the model is capable enough but the context is shallow. It does not know how the business actually works. Fabric IQ providing a shared semantic layer over structured business data combined with Work IQ could fix that at the foundation level rather than patching it per project.

Rayfin is quietly useful

Backend-as-a-service built directly into Fabric means moving from a working prototype to production without managing separate database and API infrastructure. Not a headline feature but for teams who have felt the gap between "this works in dev" and "this is running in production" it removes a real friction point.

The overall direction is clear. Every quarter the argument for keeping everything inside Fabric gets stronger and the cost of leaving gets higher.

Curious if anyone is already in the Work IQ preview or has tested Fabric IQ in a real data environment. What does the semantic layer actually look like when your source data is messy?

https://preview.redd.it/urq16myhd95h1.png?width=1254&format=png&auto=webp&s=5aa6f3cacaf952373112cb517d156e1ee50dc67a

Not a hot take, just honest observations after doing real work in Fabric after years on Synapse.

What is genuinely better

OneLake is the real win. One storage layer that everything reads from without copying data around. Synapse felt like you were always fighting data movement.

The unified workspace cuts a surprising amount of context switching. Pipelines, notebooks, semantic models, and reports all in one place actually matters day to day.

What I still miss

Capacity unit planning is opaque. I still cannot confidently estimate what a new workload will cost before running it. Synapse DWUs were clearer.

Fabric Warehouse is improving but not there yet for heavy workloads. And Mirroring is promising but I would not call it production ready for complex source systems.

Overall

I would not go back. But go in knowing it is a fast-moving platform still being built around you. If you can handle rough edges it is worth it.

Anyone else make the same switch? Curious if others feel the same way.

I migrated from Snowflake to Microsoft Fabric about 8 months ago and honestly it has been a mixed experience, Fabric wins on Power BI integration, Copilot for pipeline building, and cost consolidation, but Snowflake still feels stronger for cross-cloud data sharing and third party connectors. Once OneLake clicked for me the data architecture became much cleaner though. Has anyone else run both in production? Would love to hear real experiences not marketing answers.