Deployment pipelines and ALM

The problem: BI without lifecycle

The default Power BI workflow — open the report in the workspace, change it, save — is production editing with no review, no history, no rollback. ALM (application lifecycle management) brings the software discipline of separate environments and source control to analytics.

Deployment pipelines

A deployment pipeline links up to three workspaces as Development → Test → Production stages. You build in Dev, deploy the content up to Test to validate, then to Production for the audience. Key mechanics:

• Deployment compares stages and shows what changed before you promote — a diff, not a blind overwrite.
• Deployment rules swap stage-specific settings on promotion — most importantly data source and parameter rules so Dev points at the dev database and Prod at the prod database automatically, rather than someone hand-editing connections.
• Promotion moves reports, semantic models and other items together, keeping them consistent.

Deployment pipelines are a Premium/Fabric-capacity feature.

Fabric Git integration

Git integration connects a workspace to a repo (Azure DevOps or GitHub), so Fabric items are serialised to files and version-controlled: commits, branches, diffs, history and rollback. This enables real change review and, combined with pipelines and Azure DevOps, CI/CD for analytics. It's the difference between 'we think someone changed the model last month' and a commit that says who, what and when.

Failure modes

• Editing production directly — no test stage, so a broken measure or a bad refresh config hits the audience immediately, with no rollback.
• Manual connection swapping — promoting content and hand-editing data sources each time; error-prone, and eventually someone ships Prod pointing at Dev data (or vice versa).
• No source control — no history, no diff, no way to revert; 'who changed this and why' is unanswerable.
• Pipeline without deployment rules — Test/Prod end up querying the wrong source because the rules weren't set.
• Bypassing the pipeline — an urgent fix made straight in Prod diverges from Dev, and the next deployment overwrites it.

What to watch (proofs)

• Pipeline existence and structure: the deployment-pipelines admin surface / admin/pipelines REST endpoint — which content has a Dev/Test/Prod pipeline and which is edited raw in one workspace.
• Direct-prod editing: Get-PowerBIActivityEvent shows edit/publish operations against production workspaces by non-pipeline actors — the ungoverned changes.
• Git-connected workspaces: the scanner (admin/workspaces/getInfo) and workspace settings reveal which workspaces have Git integration — the source-control coverage gap.
• Workspace inventory by role: Get-PowerBIWorkspace -Scope Organization to see which production workspaces have broad Member access (anyone can edit) versus a controlled pipeline flow.