Deployment Pipelines

Moving Fabric content from Dev → Test → Prod

Why Separate Environments?

❌ Without Environments

Developers break production
Users see half-finished work
No way to test before go-live
No audit trail of changes

✅ With Environments

Dev is isolated from production
Test before promoting
Controlled, deliberate releases
Clear history of what deployed

Fabric Deployment Pipelines

A Fabric feature that lets you deploy content between workspaces in stages

🛠️ Development
Build & iterate
→
🧪 Test
Validate & review
→
🏭 Production
Live for users
  • Each stage is backed by a separate Fabric workspace
  • Deploy all items or selected items between stages
  • Pipelines can have 2 to 10 stages

How It Works

Dev Workspace
Lakehouse
Notebook
Semantic Model
Report
Deploy
→
Test Workspace
Lakehouse
Notebook
Semantic Model
Report
Deploy
→
Prod Workspace
Lakehouse
Notebook
Semantic Model
Report
  • Deployment copies item definitions from one workspace to another
  • Items are created or updated in the target workspace
  • Each workspace can have different data connections and security settings

Tagging Releases

Use Git tags to mark a point-in-time snapshot of your codebase

🏷️ v1
🏷️ v2
  • Tags let you label a release (e.g., v1, v2)
  • You can always go back and view what was in a release
  • Tag before you deploy — it creates a record of what went to production

The Release Workflow

1
Build and test your changes in the Dev workspace
2
Commit your changes to the Git repository
3
Tag the release in Git (e.g., v1)
4
Deploy from Dev → Test → Prod using the deployment pipeline

This gives you a repeatable, auditable release process