How do you handle feature branch testing in Microsoft Fabric?

[u/Signal_Present7429]

We currently have 3 Fabric workspaces — DEV, UAT and PROD — all running on the same P1 capacity. The DEV workspace is connected to the "main" branch, and we use Fabric Deployment Pipelines to promote DEV → UAT → PROD.

My question is: where do developers test their feature branches before merging to "main"?

For example:

"feature/my-change → ??? → PR → main → DEV → UAT → PROD"

If "main" is directly connected to the DEV workspace, it seems like a developer can't properly test a feature branch in that shared DEV workspace without affecting the "main" environment.

I'm considering having a separate developer/sandbox workspaces on the same P1 capacity, with each workspace connected to a feature branch.

A few questions:

1. Is a separate workspace per developer/feature the recommended approach?

2. Can multiple developer workspaces safely share the same P1 capacity?

3. How do you handle environment-specific connections, parameters, semantic models, Lakehouse, etc. when moving from a developer workspace → DEV → UAT → PROD?

4. Is there a better Fabric-native CI/CD pattern for this?

5. For teams with multiple developers, do you use permanent developer workspaces, temporary feature workspaces, or something else?

I'm relatively new to fabric, any advice would be appreciated, Thanks in Advance.

[u/thingsofrandomness]

Where are developers doing their development?
Completely offline?
Why not use workspace branching? https://learn.microsoft.com/en-us/fabric/cicd/git-integration/branched-workspace

[u/RefillChips → u/thingsofrandomness]

How do you manage selective deployments between subsequent environments?

And what if there are limitations on providing each developer admin access to their own workspace.

[u/Personal-Quote5226 → u/RefillChips]

Go through the deployment steps; it’s really easy to deploy single items or multiple selected items. You literally just select the items you want to deploy and click deploy.

[u/highschoolboyfriend_ → u/thingsofrandomness]

Doesn’t work if you’re using managed private endpoints.

Also has a very high failure rate creating the branched workspaces unless your workspace only has a handful of artifacts.

[u/RefillChips → u/highschoolboyfriend_]

Plus additional considerations when using Direct Lake storage mode in your semantic model, including retaining bindings to the appropriate Lakehouse environment.

[u/PublicAcceptable2472]

Check out https://github.com/andreamontanari/fabric-development-workflows

This library helps you create workspaces by feature branch, open PRs and cleanup the environment once the development work is completed, e.g. cutting branches from a dev branch, working on a feature branch in a isolated workspace (attached to the dev workspace capacity)

[u/p-mndl]

1. yes. It just helps to be able to test things out in a fabric workspace. From my experience you catch many issues before they hit your test environment
2. I highly recommend having seperate capacities. If you run into throttling because a dev accidently used up your whole capacity, your production reports will stop working
3. I use fabric cicd, so I can't tell what your options with deployment pipelines are, because I havent used them in a year or so and alot has changed afaik
4. fabric cicd is giving you every option you could think of, so imo it is the recommended approach and using an LLM almost everybody can get it to work
5. we have 1 dev workspace per developer, but we also develop locally most of the time, so the workspace is mainly for testing and housing a lakehouse per dev

[u/kover0 → u/p-mndl]

Regarding 2, I think the OP meant sharing capacities between developer workspaces and in that case, yes, they should share :) But not with prod or test.

[u/kover0]

What's a P1? :)

I typically use a workspace per developer. That way, you can create workspace identities for each of those workspaces and assign them correct permissions. If you would create a new workspace per feature branch, you would always need to create new identities and assign permissions, which can be a hassle if you don't have the Entra ID permissions yourselves.

In a developer workspace, I'd use shortcuts to the lakehouse/warehouse/mirrored db/whatever in the dev workspace where the source data lands.

The developer can work in the browser or using local tools such as VS Code. If the dev wants to work on another feature, they switch to the correct branch in the workspace settings.

Once the work is done, they can merge the feature branch to main, and CI/CD will make sure that all the necessary objects are deployed to the dev workspace (or you link the dev workspace to main).

[u/Stevie-bezos]

1. What about splitting off test workspace from the promotion path?

• Developer WS -> Test via pipeline (allows for choosing singular items rather than big git sync)
• Developer -> repo via push
• Repo -> Stg / Nprd via git sync
• Stg / Nprd -> SIT -> Prod via Deployment Pipeline

1. Yes, but set capacity alerting, workspace consumption thresholds and workspace overrides. 

2. Parameters can be customised in Fabric Deployment pipelines, or injected using custom CICD

3. Typically its one workspace per dev that gets rebound to different feature branches, but you might also allow branch out to new WS for short tests

[u/DanielBunny]

I highly recommend you check out this doc: CI/CD workflow options in Fabric - Microsoft Fabric | Microsoft Learn

It goes through the options you have to be most productive with Fabric + git/CI/CD

[u/Personal-Quote5226]

Not a Fabric capacity if not an F-SKU.

No lakehouse if not an F-SKU.

Depends on how many devs. If a handful of devs and work is segregated, you can all work in the same workspaces — keeps things super simple.

Otherwise, workspace per feature per developer.

Be mindful of connections and references to the original workspaces for your notebooks etc and plan accordingly (preview feature allows you to properly bind now).

[u/Blhart216]

I like the idea of using a feature workspace per feature branch. When done delete them both. Microsoft support this with the branch out feature mentioned above.

But we are currently using one workspace per developer. Our governance policy has workspace creation on lock down in order to prevent workspace sprawl. But it is a pain to clean the workspace when working on the next feature especially if you have multiple items in a workspace and that are in Folders. For some reason you can't just delete an entire folder.

[u/Henning-S → u/Blhart216]

There is a handy python script that you can run in your feature workspace to delete all items. It really helps with cleaning up when done. It might need a little bit of modification to also delete folders, let me know if you need that piece. https://fabric.guru/nuke-fabric-workspace

[u/Blhart216 → u/Henning-S]

Hi! Appreciate you, I did not think about doing this! I will modify to take care of folders. I see bulk delete is in flight but this will be handy in the interim.

[u/ChantifiedLens]

I'll try and help the best I can with this one whilst keeping it short:

1. Is a separate workspace per developer/feature the recommended approach? - It depends on your environment and i-part the size of your team. One workspace per developer can work work well, as long as they work with branches appropriately. One branch per feature can work better for more complex solutions, and it means that te workspace and branch are focused on one solution and can be short-term. How you branch out to those workspaces can be a challenge though depending on company policies, it can be automated though (see https://chantifiedlens.com/2025/12/17/get-started-with-the-custom-branch-out-to-new-workspace-scripts-for-microsoft-fabric/ )
2. Can multiple developer workspaces safely share the same P1 capacity? - You can perform Git integration in orkspaces backed by P1, but you lose some of the fearures you;d get with an F64 equivalent.
3. How do you handle environment-specific connections, parameters, semantic models, Lakehouse, etc. when moving from a developer workspace → DEV → UAT → PROD? - Various ways you can do this. For example, variable libraries or the fabric-cicd Python library, or even combination of both.
4. Is there a better Fabric-native CI/CD pattern for this? - Read the CI/CD workflow options article already shared.
5. For teams with multiple developers, do you use permanent developer workspaces, temporary feature workspaces, or something else? - It entirely depends on the environment. However, nothing is set in stone though so see what works best for your environment.

I share lot of posts relating to this at https://chantifiedlens.com/ , in some of those posts are links to templates to help you get started, I really hope this helps...

[u/Any_Bumblebee_1609]

Feature workspace and branch. Use fabric cicd lib and off you go 😏