2.3.3. Deployment Pipelines and Rules
💡 First Principle: Deployment pipelines automate the promotion of Fabric content through development stages—like an assembly line with quality checkpoints. Deployment rules are the "configuration translators" that swap out development settings for production settings automatically. Without rules, you'd deploy to production still pointing at your test database.
Scenario: Your lakehouse connects to a development database during development. When deploying to production, it must connect to the production database. Without deployment rules, someone would need to manually update the connection after every deployment—and eventually, they'd forget.
Deployment Pipeline Stages
- Development: Active development workspace
- Test: Quality assurance and validation
- Production: Live business operations
Deployment Rules
- Purpose: Override item settings per stage
- Common Uses:
- Change database connection strings
- Modify service endpoints
- Update parameter values
- Configuration: Set at the item level for each target stage
- Where and when: Rules are created on the target stage (never on the Development stage) and take effect on the next deployment into that stage; from then on they apply to every deployment there
- Supported items: semantic models and Dataflow Gen1 (data source and parameter rules), paginated reports and mirrored databases (data source rules), notebooks (default lakehouse rule). A data source rule can only switch to a source of the same type. A deployed Direct Lake semantic model stays bound to the source stage's lakehouse until a data source rule rebinds it
- Data pipelines have no deployment rules. Make a pipeline's connection stage-aware with a variable library (one active value set per stage) or parameters
Visual: Deployment Pipeline with Rules
Deployment Behavior
| Action | Result |
|---|---|
| Assign workspace to first stage | Workspace becomes source for pipeline |
| Assign workspace to downstream stage | Nothing is copied. Its items are paired with same-name, same-type items in the adjacent stage; the stage keeps its current (possibly empty) content until you deploy |
| Deploy to an empty stage (no workspace assigned) | A new workspace is created for that stage and the content is copied into it |
| Deploy to next stage | Paired items are overwritten and new items added; deploy everything or use selective deployment for chosen items |
| Never copied | Data (only definitions/metadata move; target items keep their own data), permissions, workspace settings |
⚠️ Exam Trap: Pipelines copy content as-is without rules. You must create deployment rules to change connection settings—they don't happen automatically. A question about "connections still pointing to dev database after deployment" is testing whether you know this.
Git integration vs. deployment pipelines: they are independent and complementary. Git keeps the history of item definitions (branches, pull requests, rollback to an earlier commit); deployment pipelines promote content between the stage workspaces. Neither requires the other.
Key Trade-Offs:
- Full Deployment vs. Selective Deployment: Full deployment ensures consistency; selective deployment allows targeted updates but risks configuration drift
- Automatic Rules vs. Manual Verification: Rules automate configuration but require careful setup to avoid production issues
Reflection Question: Your development lakehouse uses sample data from a dev database. When deployed to production without deployment rules, what will happen to the data connection?
