Forum Discussion
Helper VHow to separate dev, test, prod in fabric
Can anyone share experience, pros/cons on how to separate enviroments (dev, test, prod) in fabric?
Are you separating environments by workspace, capacity or anything else?
I have been thinking of separate capacities for each environment. This gives each environment seperate resources (dev/test will not eat on prod resources). It is also a good practise to save cost by pausing dev/test capacities while prod i running 24/7.
However I am worried that by prod cpacity/workspace is bot guarded. What security mechanisms are available? separetae accounts? Only alowwing certain deployments (depolyment pipelines etc.)?
appriciate any feedback
Hi joakimfenno,
You can assign required users the permission of the prod workspace.
BTW, fabric items also has their own security settings except workspace member permissions, you can setting on these to help increase the security of product usages.
Fabric security :
Security in Microsoft Fabric - Microsoft Fabric | Microsoft Learn
Lakehouse security:
Lakehouse sharing and permission management - Microsoft Fabric | Microsoft Learn
data warehouse security:
Security for data warehousing - Microsoft Fabric | Microsoft Learn
Regards,
Xiaoxin Sheng
7 Replies
HI joakimfenno,
For separate the different model in fabric, current you can consider two methods: Deployment pipeline and Medallion structure Lakehouse.
For the deployment pipeline, it copies the full workflow stored in three different workspaces to simulate the dev, test, fact tier of environments.
According to the above definition, you can easily to publish and cancel between these tiers, but they will spend more resources due to each tier required to store their own resource.
Overview of Fabric deployment pipelines - Microsoft Fabric | Microsoft Learn
For the 'medallion structure' Lakehouse, it is focused on the data itself instead of full workflow.
It separates the one Lakehouse workflow to three Lakehouse(they can be assign in different workspaces), then remark them as bronze, silver, gold tiers based on their business logic.
For example:
The bronze tier is used to ingest data and apply some basic data shaping operations.
The silver tier getting data from bronze and used to prepare and apply complex transform operation on the data which getting from the previous tier.
The gold tier getting the silver tier data, and it will be more focused on consume, analyze and expose result.
Implement medallion lakehouse architecture in Fabric - Microsoft Fabric | Microsoft Learn
Regards,
Xiaoxin Sheng
joakimfennodeployment pipeline is ok - assumimg that you mean that environments are swparates by workspace
but I wonder if there is a way to secure the prod workspace?
Hi joakimfenno,
You can assign required users the permission of the prod workspace.
BTW, fabric items also has their own security settings except workspace member permissions, you can setting on these to help increase the security of product usages.
Fabric security :
Security in Microsoft Fabric - Microsoft Fabric | Microsoft Learn
Lakehouse security:
Lakehouse sharing and permission management - Microsoft Fabric | Microsoft Learn
data warehouse security:
Security for data warehousing - Microsoft Fabric | Microsoft Learn
Regards,
Xiaoxin Sheng
Hi, did you manage to get your question clarified? Nobody who replied answered the question. I am facing the same challenge here. Is there an advantage of using distinct capacities to host dev, test and prod? Or is it good practive to share the same capacity? Looking for insights or documentation about it
- joakimfenno
no - not yet
just asked my Microsoft support. let's see what they say. happy to share here afterwards.
- hernandezpaulms
Microsoft Employee
Hi everyone,
I would like to add to the discussion the topic Fabric Domains.
A customer asked me to review its idea about using Fabric Domains to layout different environment:
- Domain Dev: sub-domain technical users, sub-domain business users
- Domain Test: sub-domain technical users, sub-domain business users
- Domain Prod: sub-domain technical users, sub-domain business users
I know domains suppose to be use for a decentralized architecture and usually a domain group together a business department, for example, sales or hr. Nevertheless, sometime customer got creative with usage of features and that could be a good idea (or not).
Do you see any advantage of this approach?
