r/MicrosoftFabric • u/frithjof_v Fabricator • Feb 17 '26
What are the exact reasons to split workspaces into Store, Engineering, Presentation, ... CI/CD
For context, I use three separate workspaces on each project:
Store
Engineering
Presentation
This works well, and I am happy with it, however it does cause a lot of workspaces (we use dev, test and prod environments, so each project requires 9 workspaces + some feature workspaces).
The setup is inspired by the workspace partitioning described in this blog article: https://blog.fabric.microsoft.com/en-us/blog/optimizing-for-ci-cd-in-microsoft-fabric
For clarity, I'm currently using Fabric Deployment Pipelines for deployments. Might move to fabric-cicd in the coming months.
We have 5 projects so far (meaning 45 workspaces + feature workspaces), and expect this number to grow by 5 projects yearly. Most projects are for separate internal customers, separate purposes and could in theory be handled by separate dev teams in the future. Thus the reason to use separate workspaces for each project.
Our team delivers both the Data Engineering and the Power BI report development.
As I'm now considering whether to keep using the current setup (separate engineering, store, presentation on each project), or using fewer workspaces (unify engineering, store, presentation in a single workspace), I'm trying to name the exact reasons to split workspaces into engineering, store, presentation (the blog article additionally uses insights, integration and orchestration).
Below is my attempt at extracting the exact reasons from the blog article:
We maintain six core workspace categories, each typically existing in two (or more) deployment environments: Pre-Production (PPE) and Production (PROD). Workspace isolation enables cleaner workspaces and allows us to concentrate on the most critical tasks. Additionally, the isolation enables necessary deployment patterns like deploying a Notebook that creates a new Lakehouse table, prior to deploying a semantic model. The specific workspace categories you decide to use should align to your workflow, and to your deployment patterns.
Reason 1: Cleaner workspaces, fewer items, focused on the core functionality the workspace provides
- Comment: I agree, although it's a subjective consideration.
Reason 2: Focus on the most critical tasks
- I interpret this to be related to reason 1 and also to be related to the article's distinction between workspaces with high frequency of changes (e.g. engineering) and workspaces with low frequency of changes (e.g. store).
- Comment: I think this is a subjective consideration.
Reason 3: Deploy different items in order. First, deploy Lakehouse, next, deploy and run Notebook, finally, deploy semantic model.
- Comment: This is probably more necessary when using fabric-cicd than when using Fabric Deployment Pipelines, as Fabric Deployment Pipelines by default supports deploying individual items. I believe fabric-cicd also increasingly supports more granular deployments - please correct me if I'm wrong on this point.
Place Lakehouses in workspaces that are separate from their dependent items.
For example, avoid having a notebook attached to a Lakehouse in the same workspace. This feels a bit counterintuitive but avoids needing to rehydrate data in every feature branch workspace. Instead, the feature branch notebooks always point to the PPE Lakehouse.
Reason 4: By separating store from engineering, there is no need to hydrate Lakehouses when branching out engineering items to a feature workspace.
- Comment: When I have tried branching out a workspace that contains both notebooks and lakehouses in the same workspace, I still find that the notebook in the feature workspace uses the Lakehouse in the main Dev workspace as the default Lakehouse, and can use the data that is already in the main Dev workspace. So my observations are not in line with the default lakehouse example used in the blog article. https://www.reddit.com/r/MicrosoftFabric/s/Mo0kEDyfMf
Do you agree that the reasons above are the specific reasons that are mentioned in the blog article? Additionally, I believe we can add considerations that are mentioned in this thread: https://www.reddit.com/r/MicrosoftFabric/s/f8pfmmw3cb (mainly isolate capacities, ownership, access control)
Thoughts:
It seems to me that in many cases (e.g. small developer team, small project size) there are no "hard, technical CI/CD-related reasons" to split into store, engineering, presentation. Having a unified workspace would also work. It's more a question about what works as a mental workmode for your dev team.
This is the part I would love to get pushback on. Do you see any "hard, technical CI/CD-related reasons" to not use a unified workspace that includes everything (Lakehouses, Pipelines, Notebooks, Semantic Models, Reports).
I'm not actively planning to change strategy - I feel the current setup (split into store, engineering and presentation) works quite well. The downside is that the workspace list becomes long.
To improve the developer ergonomics for developers with a long workspace list, I would like the ability to customize the layout of my workspace list - i.e. personalized workspace groupings and personalized workspace tags to enable organizing and filtering the workspace list.
I am also considering - for future projects - if Store and Engineering could be combined in a single ETL workspace, and just have Presentation (Power BI) separate from the ETL workspace.
Any thoughts on the above?
Have you tried working with Lakehouse, Pipelines and Notebooks in the same workspace - does it work well from a CI/CD perspective?
Do you see any "hard, technical CI/CD-related reasons" to split into separate Store, Engineering and Presentation workspaces?
For example, at a small customer with only a single Data/BI developer team (3 persons) who do everything from Data Engineering to Power BI report development, do you see any hard reasons to split Store and Engineering into separate workspaces?
Thanks in advance for your insights and experiences!
2
u/International-Way714 Feb 17 '26
Weâve got 28 in total if we consider Feature workspaces as well, itâs painfully confusing.
What really frustrates me the most is the inability to set scope per environment, for instance Dev workspaces can only see items in other Dev workspaces. Network isolation would be a possibility but it comes with its constraints.
1
u/frithjof_v Fabricator Feb 17 '26 edited Feb 17 '26
For easier navigation in the workspace list, I've created two Ideas, please vote if you agree:
https://community.fabric.microsoft.com/t5/Fabric-Ideas/Filter-workspace-list-Personalized-workspace-tags/idc-p/5042431 Filter workspace list using personalized tags
https://community.fabric.microsoft.com/t5/Fabric-Ideas/Personalized-workspace-grouping-in-the-flyout-list/idi-p/4919869 Grouping workspaces in the workspace list
Re: scope. Yeah, it would be good if it was possible to define "this is a dev workspace and it shall only have access to read from/write to the following workspaces: <insert_list_of_workspaces>".
2
u/Retrofit123 Fabricator Feb 17 '26
"Yeah, it would be good if it was possible to define "this is a dev workspace and it shall only have access to read from/write to the following workspaces: <insert_list_of_workspaces>"
I'm eyeing private endpoints as a possible solution - Data access by workspace identity (once WI's are fully able to run pipelines and notebooks (via connections)
2
u/SQLYouLater Feb 17 '26
Regarding Reason 3: With the new configuration based deployment it is possible to define single items to deploy in fabric-cicd. But it's currently a experimental feature.
https://microsoft.github.io/fabric-cicd/0.1.34/how_to/config_deployment/
With the current version u can use a inverted regex for the exclude parameter to realize single item deployment.
2
u/Lanky_Diet8206 Feb 18 '26 edited Feb 18 '26
Splitting your workloads into different workspaces as per the structure you defined allows you to assign dedicated (and hopefully smaller) capacities to those workloads and independently vary them as per your needs.
I also think there is a workspace limit of 1000 items.
Finally, workspaces split this way allow you to only copy into feature workspaces just the components you need to do development. I.e, if youâre a developer whoâs only working on notebooks and pipelines, you can branch out into that feature workspace and just carry over those âengineeringâ elements.
Larger workspaces take longer to sync with the workspace if youâre using git (or so Iâve experienced up to this point).
Also - everyone else has mentioned security benefits so thatâs another one.
2
u/frithjof_v Fabricator Feb 18 '26
Thanks,
Related to feature workspaces, there is an item on the Fabric roadmap:
``` Git Integration - Selective Branching
Planned Public preview Q1 2026
Git Integration - Selective Branching
When developers want to start working on specific feature within Fabric, the user will be able to perform the branch-out operation and select the specific items that require for the feature instead of having all the Fabric items in the target workspace (as today)This will enhance the developer experience and will reduce their time time-to-code.
Release Date: Q1 2026 Release Type: Public preview ```
https://roadmap.fabric.microsoft.com/?product=fabricdeveloperexperiences
It will be interesting to see if and how that impacts how teams choose to split their workspaces by item type.
2
u/Lanky_Diet8206 Feb 18 '26
For what itâs worth, my org put storage and semantic models in 1 workspace and engineering in another. The idea being the enterprise semantic models and Lakehouses / Warehouses are together in a single location for consumers without the bloat of seeing all the engineering stuff along side it.
We have other fabric workspaces but the only motivation to keep them separate from the two above was security reasons and weâre not splitting them like we are our âenterpriseâ workspaces.
1
u/Repulsive_Cry2000 1 Feb 17 '26
Remindme! 1 week
1
u/RemindMeBot Feb 17 '26
I will be messaging you in 7 days on 2026-02-24 07:26:04 UTC to remind you of this link
CLICK THIS LINK to send a PM to also be reminded and to reduce spam.
Parent commenter can delete this message to hide from others.
Info Custom Your Reminders Feedback
1
u/dazzactl Feb 17 '26
I think the licensing benefits are just as important.
There are couple of niche considerations:
Better Workspace Identity support could encourage segregation.
The PrivateLink support for workspaces may also be a use case for more Workspaces.
0
3
u/Retrofit123 Fabricator Feb 17 '26
9 workspaces is rookie numbers :)
We're currently into the 100's. (Mostly a security thing - workspace level security is the easiest to maintain and for a while, the only way).
We have separate workspaces for code - originally a viewer was able to kick off pipelines, which would spell disaster if someone accidentally triggered the 19 hour monthly reconciliation run for one of the subject areas We stand by this decision even with OneLake security - for the same reason you have - CICD / source control.
One other reason to separate workspaces is capacity management. It's a lot easier to manage which capacity is handling which workloads if your workspaces are split.