Posted by Pip: If you have ever manually copied a report from a dev workspace to production and immediately regretted it, Praveen Kumar Sreeram's blog has a message for you.
Mara: This episode goes deep on Microsoft Fabric Deployment Pipelines — the built-in tool for promoting content across environments without the manual chaos. Let's start with what deployment pipelines actually are and why the whole CI/CD workflow depends on getting them right.
Microsoft Fabric Deployment Pipelines — A Complete Deep Dive
Mara: Deployment Pipelines are Microsoft Fabric's native Application Lifecycle Management tool, and the post frames the problem they solve directly: "Before deployment pipelines existed, teams would manually recreate or copy items between workspaces when moving from development to production. This was slow, error-prone, and almost impossible to audit."
Pip: So the upshot is that promotion becomes a single click, configurations get overridden automatically via rules, and every deployment is logged. Three problems, one mechanism.
Mara: The pipeline model is straightforward: each stage represents an environment — Dev, Test, Prod — backed by a dedicated Fabric workspace. Content moves left to right. And the constraints matter here: two stages minimum, three by default, ten maximum, with exactly one workspace per stage and no sharing across pipelines.
Pip: One workspace per stage sounds obvious until you try to reassign one and discover that unassigning it permanently deletes all deployment history and configured rules — irreversible, no undo.
Mara: That irreversibility is a recurring theme. Item pairing — how Fabric knows which target item to overwrite — works on name, type, and folder location. Renaming a folder, even without touching its contents, marks every paired item as different from source and forces a re-deployment to resync.
Pip: A folder rename triggering a full re-deploy is the kind of thing that only appears in the known limitations section after someone finds it the hard way.
Mara: The post covers three deployment modes: deploy all content for full milestone releases, selective deployment for targeted promotions using the Select Related button to pull in dependent items automatically, and backward deployment for pushing production content back to an earlier stage — but only when that earlier stage has no workspace assigned.
Mara: Deployment Rules are what make multi-environment pipelines safe in practice. Data Source Rules redirect connections at deploy time; Parameter Rules override Power Query parameter values per stage. The post is explicit: configure rules before your very first deployment, because the first deploy will otherwise carry dev connections straight into production.
Pip: Variable Libraries handle the runtime side — environment-specific key-value pairs read by notebooks and data pipelines during execution, versioned as Fabric items and visible in the compare view before promotion. Rules cover deploy time; libraries cover run time.
Mara: And the compare view itself is the checkpoint before every deployment — green means stages are in sync, orange means at least one item differs and you should review before promoting.
Pip: Structured promotion, automatic rule application, runtime configuration — the whole system is designed to make the manual-copy era feel as avoidable as it always was.
Mara: More from the Microsoft Fabric CI/CD series ahead.
Praveen Kumar Sreeram's Blog 