Module 11
CI/CD & DevOps
11.6 Deploy Across Workspaces — Complete Microsoft Fabric + Azure DevOps Guide
Module 11 · Lesson 11.1
Git Integration
Module 11 · Lesson 11.2
Deployment Pipelines
Module 11 · Lesson 11.3
Workspace Promotion
Module 11 · Lesson 11.4
Environment Management
Module 11 · Lesson 11.5
GitHub Integration
Module 11 · Lesson 11.6
Deploy Across Workspaces
11.6 Deploy Across Workspaces — Complete Microsoft Fabric + Azure DevOps Guide
For a real Microsoft Fabric project, I recommend thinking about deployment as two separate but connected processes:
Azure DevOps Git = source control and collaboration
Fabric Deployment / CI/CD = promotion from DEV → TEST → PROD
Microsoft's current Fabric CI/CD tooling supports Git integration with Azure DevOps and multiple approaches for automating deployments. (Microsoft Learn)
A production architecture typically looks like this:
DEVELOPERS
│
▼
┌──────────────────┐
│ FABRIC DEV │
│ WORKSPACE │
│ │
│ Lakehouse │
│ Pipelines │
│ Notebooks │
│ Dataflows Gen2 │
│ Warehouse │
│ Semantic Models │
│ Reports │
└────────┬─────────┘
│
Git Integration
│
▼
┌──────────────────┐
│ AZURE DEVOPS │
│ │
│ Azure Repos │
│ Branches │
│ Pull Requests │
│ Code Reviews │
│ Pipelines │
└────────┬─────────┘
│
▼
Approved Code
│
▼
┌──────────────────┐
│ FABRIC TEST │
│ WORKSPACE │
└────────┬─────────┘
│
Testing / UAT
│
Approval
│
▼
┌──────────────────┐
│ FABRIC PROD │
│ WORKSPACE │
└──────────────────┘
This is the overall idea behind 11.6 Deploy Across Workspaces.
1. What does "Deploy Across Workspaces" mean?
Suppose your organization has three Fabric workspaces:
Fabric │ ├── Sales-DEV │ ├── Sales-TEST │ └── Sales-PROD
Developers should not develop directly in PROD.
Instead:
Developer
↓
DEV
↓
TEST
↓
PROD
For example, you create a new notebook:
NB_Load_Customers
You don't manually recreate it three times.
You develop it once:
DEV
↓
Version Control
↓
Deploy
↓
TEST
↓
Validate
↓
Deploy
↓
PROD
2. Why Azure DevOps?
Microsoft Fabric CI/CD documentation
Azure DevOps provides capabilities such as:
Azure DevOps
│
├── Repos
│ └── Git source control
│
├── Branches
│ └── Development workflow
│
├── Pull Requests
│ └── Code review
│
├── Pipelines
│ └── Automation
│
└── Environments
└── Deployment approvals
Fabric's native Git integration can synchronize workspace items with an Azure DevOps Git repository. (Microsoft Learn)
3. Git integration vs Deployment Pipeline
This distinction is extremely important.
| Feature | Purpose |
|---|---|
| Git Integration | Version control |
| Azure DevOps Repo | Store Fabric definitions |
| Branches | Isolate development |
| Pull Requests | Review changes |
| Fabric Deployment Pipeline | Promote between workspaces |
| Azure Pipeline | Automate CI/CD |
| Fabric REST API / fabric-cicd | Programmatic deployment |
Think:
Git Integration
↓
"What changed?"
Deployment Pipeline
↓
"Where should this version go?"
4. Recommended workspace architecture
For your learning project, create:
FABRIC TRAINING PROJECT │ ├── Fabric-DEV │ ├── Fabric-TEST │ └── Fabric-PROD
For a company project, naming might look like:
EDW-Fabric-DEV
EDW-Fabric-TEST
EDW-Fabric-PROD
Each environment represents a separate lifecycle stage.
5. What should exist inside the workspaces?
For example:
EDW-Fabric-DEV │ ├── LH_EDW │ ├── WH_EDW │ ├── PL_Load_Customers │ ├── PL_Load_Orders │ ├── NB_Transform_Customers │ ├── NB_Transform_Sales │ ├── DF_Customer_Cleanup ├── Semantic Model └── Reports
After promotion, corresponding supported items can exist in:
EDW-Fabric-TEST
and eventually:
EDW-Fabric-PROD
But be aware that support varies by Fabric item type, and some item types/features are still preview or have deployment limitations. Always check the current supported-items documentation before designing the pipeline.
6. Step 1 — Create an Azure DevOps project
Open Azure DevOps and create something like:
Organization
↓
Project
↓
Fabric-EDW
Inside the project:
Fabric-EDW │ ├── Boards ├── Repos ├── Pipelines ├── Test Plans └── Artifacts
For Fabric CI/CD, we're primarily interested in:
Repos +
Pipelines
7. Step 2 — Create Azure Repo
Go to:
Azure DevOps
↓
Fabric-EDW Project
↓
Repos
Create/select a repository:
fabric-edw
Conceptually:
Azure DevOps
│
└── Repos
│
└── fabric-edw
This repository will store the definitions of supported Fabric items.
8. Step 3 — Decide your branch strategy
For a beginner project, you might think in terms of:
main │ └── feature/*
For example:
main
feature/customer-pipeline
feature/sales-notebook
feature/order-transformation
A developer creates:
feature/customer-pipeline
makes changes and raises a Pull Request.
feature/customer-pipeline
↓
Pull Request
↓
Review
↓
main
For more automated enterprise CI/CD, Microsoft also documents patterns using long-lived dev, test, and prod branches. Its current Azure DevOps + fabric-cicd tutorial, for example, connects DEV to dev, while test and prod record promoted versions and deployment is handled by the CI/CD tooling. (Microsoft Learn)
So branch strategy should match the deployment model you choose.
9. Step 4 — Enable Fabric Git integration
Your Fabric administrator must allow Git integration.
The relevant tenant setting allows users to synchronize workspace items with Git repositories. (Microsoft Learn)
Conceptually:
Fabric Admin Portal
↓
Tenant Settings
↓
Git Integration
↓
Enable
You may need your Fabric administrator if you can't see or use the Git options.
10. Step 5 — Connect Fabric DEV to Azure DevOps
Microsoft documentation: Fabric Git integration process
Open:
Microsoft Fabric
↓
DEV Workspace
Then:
Workspace settings
↓
Source control
↓
Connect
Select:
Azure DevOps
You'll configure information such as:
Azure DevOps organization
Project
Git repository
Branch
Folder
For example:
Organization:
mycompany
Project:
Fabric-EDW
Repository:
fabric-edw
Branch:
main
or whichever branch your workflow uses.
11. What happens after connection?
Now:
Fabric DEV Workspace
↕
Azure DevOps Git
Fabric can show synchronization status between the workspace and repository.
Conceptually:
Fabric
PL_Load_Customers
NB_Transform_Sales
LH_EDW
↓ Commit
Azure DevOps
PL_Load_Customers/
NB_Transform_Sales/
LH_EDW/
Fabric serializes supported item definitions into Git-trackable representations. (Microsoft Learn)
12. Important: Git isn't backing up all your Lakehouse data
This is a critical concept.
For Lakehouse, Fabric Git integration tracks metadata, not the actual data stored in tables/files.
Microsoft specifically states that Lakehouse tables and Files data aren't versioned in Git, and Git/deployment operations don't overwrite that data. (Microsoft Learn)
So:
Lakehouse │ ├── Definition / metadata → Git ✓ │ └── Actual TBs of data → Git ✕
You are not pushing terabytes of Parquet data into Azure DevOps.
13. Step 6 — Developer makes changes
Suppose you modify:
NB_Transform_Customers
in DEV.
Fabric detects a difference:
Workspace Version
≠
Git Version
You can commit the change.
Conceptually:
Developer
↓
Fabric DEV
↓
Modify Notebook
↓
Commit
↓
Azure DevOps
Now the notebook definition is version controlled.
14. Step 7 — Pull Request
In a controlled enterprise process:
Developer Branch
↓
Pull Request
↓
Reviewer
↓
Approve
↓
Merge
For example:
feature/sales-transformation
↓
PR
↓
main
Benefits:
Code Review
Change History
Approval
Auditability
Rollback capability
15. Step 8 — Create Fabric Deployment Pipeline
Now we move from source control to environment promotion.
Microsoft guide: Get started with Fabric deployment pipelines
Create a deployment pipeline in Fabric.
For example:
EDW Deployment Pipeline
Configure stages representing:
Development
↓
Test
↓
Production
The current Fabric deployment-pipeline experience supports assigning workspaces to pipeline stages. (Microsoft Learn)
16. Step 9 — Assign workspaces
Assign:
Development
↓
EDW-Fabric-DEV
Test
↓
EDW-Fabric-TEST
Production
↓
EDW-Fabric-PROD
Architecture:
EDW Deployment Pipeline
┌────────────────┐
│ Development │
│ │
│ Fabric-DEV │
└───────┬────────┘
│
▼
┌────────────────┐
│ Test │
│ │
│ Fabric-TEST │
└───────┬────────┘
│
▼
┌────────────────┐
│ Production │
│ │
│ Fabric-PROD │
└────────────────┘
17. Step 10 — Deploy DEV → TEST
Suppose DEV contains:
PL_Load_Customers
NB_Transform_Customers
LH_EDW
After development and review:
DEV
↓
Deploy
↓
TEST
Fabric lets you select supported content for deployment. Deploying source items can overwrite their paired target-stage items; items absent from the source aren't simply deleted automatically as part of an ordinary deployment. (Microsoft Learn)
When deploying into an empty stage, Fabric preserves supported item relationships—for example, relationships between reports and semantic models. (Microsoft Learn)
18. TEST environment
TEST is where you validate the solution.
TEST │ ├── Functional Testing ├── Integration Testing ├── Data Validation ├── Performance Testing ├── Security Testing └── UAT
For a data pipeline:
Pipeline
↓
Run
↓
Check Success
↓
Validate Row Counts
↓
Validate Data
↓
Validate Business Rules
Only after validation should the release move to PROD.
19. Step 11 — Deploy TEST → PROD
After testing:
TEST
↓
Approval
↓
PROD
Conceptually:
DEV │ │ Develop ▼ TEST │ │ Validate ▼
PROD
The production workspace should ideally be treated as controlled deployment territory rather than a development environment.
20. Environment-specific configuration
This is one of the biggest real-world issues.
Imagine your DEV pipeline connects to:
Server:
sql-dev.company.com
Database:
SalesDEV
TEST should use:
sql-test.company.com
SalesTEST
PROD:
sql-prod.company.com
SalesPROD
You do not want the PROD deployment continuing to connect to DEV.
21. Use environment-specific configuration
Conceptually:
SAME CODE
│
┌──────────┼──────────┐
▼ ▼ ▼
DEV TEST PROD
Server DEVSQL TESTSQL PRODSQL
DB SalesDev SalesTest SalesProd
Fabric supports lifecycle-management approaches for handling environment-specific references and configuration; Variable Libraries are also part of Fabric's current CI/CD tooling. (Microsoft Learn)
This is preferable to hardcoding:
server = "devserver"
throughout notebooks.
22. Example notebook design
Bad:
server = "sql-dev.company.com" database = "SalesDEV"
because when deployed to PROD it can still point at DEV.
Better architectural thinking:
Notebook
↓
Environment configuration
↓
DEV → DEV values
TEST → TEST values
PROD → PROD values
The code remains logically consistent while configuration changes by environment.
23. Connections and credentials
Treat these differently from normal code.
Don't store passwords in notebooks or Git:
password = "MyProductionPassword123"
Never commit secrets like that to Azure DevOps.
Instead use appropriate Fabric/Azure connection and secret-management mechanisms.
For fully automated Azure DevOps CI/CD, Microsoft demonstrates Azure Key Vault + Azure DevOps variable groups + a service principal. (Microsoft Learn)
Conceptually:
Azure DevOps Pipeline
↓
Secure Authentication
↓
Fabric API
24. Option A — Native Fabric Deployment Pipelines
For learning 11.6 Deploy Across Workspaces, start here.
Azure DevOps
↓
Version Control
Fabric DEV
↓
Deployment Pipeline
↓
Fabric TEST
↓
Deployment Pipeline
↓
Fabric PROD
Advantages:
Simple
Visual
Fabric-native
Easy to understand
Good for learning
Microsoft explicitly documents this hybrid model: Git up to the development stage, then Fabric deployment pipelines to TEST and PROD. (Microsoft Learn)
25. Option B — Azure DevOps automated CI/CD
For enterprise automation:
Developer
↓
Git Commit
↓
Pull Request
↓
Merge
↓
Azure Pipeline
↓
Authenticate
↓
Fabric APIs / deployment tooling
↓
TEST
↓
Tests
↓
Approval
↓
PROD
This is closer to traditional DevOps.
26. fabric-cicd
Microsoft now documents an open-source Python package called fabric-cicd for code-first Fabric deployments.
Microsoft Fabric fabric-cicd documentation
It provides an abstraction over Fabric REST APIs and is designed to work with Azure Pipelines and other CI/CD systems. (Microsoft Learn)
Installation:
pip install fabric-cicd
Microsoft currently documents Python 3.9–3.13 as supported for the package. (Microsoft Learn)
27. Enterprise Azure DevOps architecture
A more advanced architecture is:
DEVELOPERS
│
▼
FABRIC DEV
│
▼
AZURE DEVOPS
│
Azure Repos
│
Pull Request
│
MAIN
│
▼
AZURE PIPELINE
│
┌──────────┴──────────┐
│ │
Build/Test Authentication
│ │
└──────────┬──────────┘
▼
fabric-cicd
│
Fabric REST APIs
│
▼
FABRIC TEST
│
Automated Tests
│
▼
Approval / Gate
│
▼
FABRIC PROD
This allows deployment without someone manually clicking Deploy.
28. Azure Pipeline YAML concept
An Azure DevOps pipeline may conceptually contain:
trigger:
branches:
include:
- main
stages:
- stage: Validate
jobs:
- job: ValidateFabric
- stage: DeployTest
jobs:
- job: DeployToTest
- stage: Test
jobs:
- job: RunTests
- stage: DeployProd
jobs:
- job: DeployToProduction
The actual Fabric deployment commands can use Microsoft's supported APIs/tooling.
Don't treat this illustrative YAML as a ready-to-run production pipeline—the authentication, workspace IDs, item scope, parameters, and deployment commands still need to be configured.
29. Service Principal
For automation, you don't want:
Sreehari's User Account
↓
Production Deployment
because the deployment would depend on one employee's interactive identity.
A better enterprise pattern is:
Azure DevOps
↓
Service Principal
↓
Microsoft Fabric
Microsoft now documents service-principal-based Azure DevOps Git integration and automated Fabric CI/CD scenarios. (Microsoft Learn)
30. CI vs CD
Very common interview question.
CI — Continuous Integration
Developer
↓
Commit
↓
Git
↓
Pull Request
↓
Validation
↓
Merge
Purpose:
Ensure changes are safely integrated into the codebase.
CD — Continuous Delivery/Deployment
Approved Version
↓
DEV
↓
TEST
↓
PROD
Purpose:
Move tested versions safely between environments.
31. Fabric CI/CD
Therefore:
CI
│
Developer → Git → PR → Review
│
▼
MAIN
│
│
CD
▼
DEV
↓
TEST
↓
PROD
32. Example end-to-end project
Suppose you have:
PL_Load_Sales
NB_Clean_Sales
NB_Sales_Gold
LH_Sales
Sales Semantic Model
Sales Dashboard
Developer changes:
NB_Clean_Sales
Flow:
1. Modify notebook in DEV
↓
2. Commit change
↓
3. Azure DevOps repository
↓
4. Pull Request
↓
5. Code review
↓
6. Merge approved version
↓
7. Synchronize/deploy DEV
↓
8. Deploy DEV → TEST
↓
9. Run tests
↓
10. Validate data
↓
11. UAT approval
↓
12. Deploy TEST → PROD
↓
13. Validate production
↓
14. Monitor
That's a complete release lifecycle.
33. Lakehouse deployment warning
This is particularly important for your Fabric learning.
Suppose:
DEV Lakehouse
FactSales
100 GB
Deploying the Lakehouse definition doesn't mean:
100 GB DEV Data
↓
Copied into TEST
Fabric's Lakehouse lifecycle management tracks metadata rather than copying the underlying Files/Tables data. (Microsoft Learn)
Instead:
DEV
Lakehouse Definition
↓
Deployment
↓
TEST
Lakehouse Definition
Then TEST pipelines/data processes populate or reference the appropriate TEST data.
34. Notebook deployment
Fabric notebooks support Git integration and deployment pipelines. Notebook dependencies can also maintain supported bindings through lifecycle operations. (Microsoft Learn)
For example:
NB_TransformSales
│
▼
DEV Environment
After deployment:
NB_TransformSales
│
▼
TEST Environment
You should define deployment/configuration rules on the target stage where applicable rather than hardcoding DEV references. (Microsoft Learn)
35. Real-Time Intelligence items
Since you also studied Eventstream and Eventhouse, this matters.
Fabric currently supports Git/deployment lifecycle management for Real-Time Intelligence items including:
Eventstream
Eventhouse / KQL database
KQL queryset
Real-time dashboard
Activator (preview)
(Microsoft Learn)
But cross-workspace Eventstream scenarios have limitations. Microsoft recommends care around destinations, and Direct Ingestion destinations may require connection reconfiguration after deployment. (Microsoft Learn)
36. What should NOT go into Git?
Don't think of Azure DevOps as a dump of everything in Fabric.
Generally:
CODE / DEFINITIONS
↓
Git
Examples:
Notebook definitions
Pipeline definitions
Supported item metadata
Configuration templates
Deployment scripts
Documentation
Not:
Passwords
Secrets
Production credentials
Terabytes of Lakehouse data
Temporary files
37. Deployment approval strategy
For a company environment:
DEV │ │ Developer controlled ▼ TEST │ │ QA / UAT Approval ▼
PROD
Production deployment could require:
Tech Lead Approval
+
Business/UAT Approval
+
Release Approval
Azure DevOps Environments can provide approval gates in an automated pipeline design; Microsoft's current fabric-cicd tutorial demonstrates this pattern. (Microsoft Learn)
38. Rollback strategy
Suppose:
Version 10
is deployed to PROD.
Then users report a critical problem.
Because Git contains history:
v8
v9
v10 ← bad
you can identify a known-good version and follow your controlled deployment process to restore/redeploy it.
This is a major reason Git matters.
Without source control:
"What changed?"
Nobody knows.
With Git:
Commit History
↓
PR
↓
Author
↓
Changes
↓
Previous Version
39. Don't manually change PROD
One of the most important enterprise rules:
Developer
↓
PROD
↓
Edit Notebook
❌ Avoid this.
Prefer:
Developer
↓
DEV
↓
Git
↓
PR
↓
TEST
↓
Approval
↓
PROD
Otherwise your environments can drift.
40. Environment drift
Suppose:
DEV Notebook
Version 12
TEST Notebook
Version 11
PROD Notebook
Version 8 + manual fix
Now nobody knows what PROD really contains.
That's:
Environment drift
A good CI/CD process aims for:
Git
↓
Controlled version
↓
DEV
↓
TEST
↓
PROD
with traceability.
41. Recommended setup for learning
For your Fabric syllabus, build this hands-on lab:
Azure DevOps
Project:
FabricTraining
Repo:
fabric-training
Create:
FabricTraining-DEV
FabricTraining-TEST
FabricTraining-PROD
In DEV create:
LH_Sales
NB_LoadSales
NB_TransformSales
PL_Sales_ETL
Then practice:
DEV
↓
Azure DevOps Git
↓
Commit
↓
Change Notebook
↓
Commit Again
↓
View Difference
↓
Create Deployment Pipeline
↓
DEV → TEST
↓
Validate
↓
TEST → PROD
If you can complete this lab yourself, you'll understand most of the practical concepts behind 11.6 Deploy Across Workspaces.
42. Recommended enterprise approach
For an organization moving toward Fabric, I'd structure the lifecycle as:
AZURE DEVOPS
│
┌────────┴────────┐
│ │
Azure Repo Azure Pipeline
│ │
Versioning Automation
│ │
└────────┬────────┘
│
▼
FABRIC DEV
│
▼
TEST
│
Automated Tests
│
UAT / Approval
│
▼
PROD
│
▼
MONITOR
For your first implementation, however, use:
Azure DevOps Git + Fabric Deployment Pipelines
before moving to full REST API / fabric-cicd automation.
That makes the concepts much easier to understand.
43. Interview question — How do you deploy Fabric items across workspaces?
A strong answer:
I separate environments into DEV, TEST, and PROD workspaces. The DEV workspace is integrated with Git, such as Azure DevOps, for version control, branching, pull requests and code reviews. Approved changes are then promoted through Fabric deployment pipelines or an automated CI/CD process. Environment-specific connections and configuration are handled separately so the same logical solution can point to DEV, TEST, and PROD resources appropriately.
44. Interview question — Git integration vs Deployment Pipelines?
Git integration provides source control, collaboration and version history for supported Fabric items. Deployment pipelines promote supported Fabric content between environment workspaces such as DEV, TEST and PROD. Git answers which version we have; deployment pipelines control where that version is promoted.
45. Interview question — Does Fabric Git integration store Lakehouse data?
No. For Lakehouse Git integration, Fabric tracks the Lakehouse definition and supported metadata, not the actual table and Files data. The data remains in OneLake and isn't copied into Azure DevOps. (Microsoft Learn)
46. Interview question — How do you handle DEV/TEST/PROD connections?
I avoid hardcoding environment-specific server names, workspace IDs, Lakehouse IDs and credentials. Instead, I externalize environment-specific configuration and use Fabric deployment configuration/Variable Libraries or CI/CD parameterization, with credentials managed securely.
47. Interview question — How would you automate Fabric deployment with Azure DevOps?
I would keep Fabric definitions in an Azure DevOps repository, use pull requests for controlled merges, and trigger an Azure Pipeline after approval. The pipeline would authenticate using a service principal or another supported workload identity and use Fabric deployment APIs or Microsoft's fabric-cicd tooling to deploy to TEST. After automated validation and approval gates, the pipeline would deploy the approved version to PROD. (Microsoft Learn)
48. The complete diagram to remember
DEVELOPER
│
▼
FEATURE BRANCH
│
▼
FABRIC DEV
│
Git Commit
│
▼
┌────────────────┐
│ AZURE DEVOPS │
│ │
│ Azure Repos │
│ Git History │
│ Pull Requests │
│ Code Review │
└───────┬────────┘
│
APPROVE
│
▼
MAIN
│
▼
CI/CD PROCESS
│
┌─────────────┴─────────────┐
│ │
Fabric Deployment Azure Pipeline
Pipeline +
│ Fabric APIs /
│ fabric-cicd
│ │
└─────────────┬─────────────┘
▼
FABRIC TEST
│
Functional Test
Data Validation
Performance Test
UAT
│
APPROVAL
│
▼
FABRIC PROD
│
▼
MONITOR
Quick revision
| Component | Purpose |
|---|---|
| Fabric DEV | Development |
| Azure DevOps Repo | Source control |
| Git Branch | Isolate changes |
| Pull Request | Review changes |
| Main/approved branch | Approved source |
| Fabric Deployment Pipeline | Promote content |
| Fabric TEST | Testing/UAT |
| Fabric PROD | Production |
| Azure Pipeline | CI/CD automation |
| Service Principal | Automated identity |
| Fabric REST APIs | Programmatic Fabric operations |
| fabric-cicd | Code-first Fabric deployment |
| Variable/configuration layer | Environment-specific values |
| Key Vault / secure store | Secrets |
| Monitoring | Validate production health |
The flow to memorize for interviews
Develop → Commit → Pull Request → Review → Merge → Deploy DEV → TEST → Validate → Approve → Deploy PROD → Monitor
And remember the three responsibilities:
Azure DevOps Git = Version Control Fabric/Azure DevOps CI/CD = Deployment Automation DEV → TEST → PROD = Environment Promotion
For your syllabus, this is the complete mental model for 11.6 Deploy Across Workspaces. The official Microsoft guidance also recognizes both Fabric-native deployment pipelines and Azure DevOps/API-based automation, so you can start simple and later evolve the same design into enterprise CI/CD. (Microsoft Learn)
↑ Back to top