Deployment pipelines are great, almost a requirement for managing Datasets and Dataflows. It’s important to have centrally managed data models that can be developed and promote to Test and Production. Read more about them here:
https://learn.microsoft.com/en-us/power-bi/create-reports/deployment-pipelines-overview
The benefits include:
- Automatically change parameter settings via Deployment rules.
- Unlike the Power BI Desktop Publish process, only the metadata gets copied to the Test and Production Dataset. The data only changes when you perform a Refresh.
- Can test changes to your data model prior to deploying to production.
- It’s a good excuse to get your company to invest in Power BI Premium Per User. Deployment Pipelines don’t work with Power BI Pro.
Deployment Pipelines for Reports
Deployment Pipelines will work for reports, but there is a poorly documented feature I want to highlight.
Reports can be linked to a Dataset in the same workspace (wrong) or a separate data model workspace (correct). When setting up a Report Pipeline, it gets confusing because it’s no longer possible to use Deployment Rules. Instead, there’s some secret automagical logic under the covers in Power BI that will repoint Reports to the appropriate Dataset.
If the Report is in a Pipeline-enabled Test Workspace, and the Dataset is in a Pipeline-enabled Test Workspace, then when deploying the Report to the Production Workspace it will get auto-binded to the Production Dataset with the same name.
Below is a diagram of what I think is a good pipeline structure.
Microsoft does have an article about this, but I found it confusing.
https://learn.microsoft.com/en-us/power-bi/create-reports/deployment-pipelines-process#auto-binding
Joel Leichty 