Power BI Deployment for CICD - Multiple Production Workspaces

[jonesb321]

Core Problem:

New-PowerBIReport -Path 'somefile.pbix' -WorkspaceId 'someworkspaceid' -ConflictAction CreateOrOverwrite creates duplicate instances of the report. 

The caveat here is that both of the reports have different datasetids associated to them.  I could delete the old report, but then I would have to update any references to the reportid.

Requirements:

I have a set of predefined reports that I want to distribute across multiple workspaces.  Each workspace has its own dataset, but it is based on a common data model defined in the DEV tier.  The only difference between the datasets should be the datasource: different Azure Sql and credentials.  All of these reports will be delivered to the end users via the embedded "App Owns Data" approach.  All PBIX files will be maintained in an Azure Git repot and deployed via an Azure DevOps CICD process.

Preamble:

I have a DataModel.pbix file published to my "dev" workspace that contains the common dataset.

I have multiple report PBIX files which have a reference to the online dataset within the dev workspace.

All of the physical PBIX files exist in an Azure Git repo under either the dataset or reports folders, as appropriate.

I have a Build Pipeline that is generating the build artifacts for use in a release pipeline.

Note:

I've tried a few of the Power BI marketplace extensions, but since they still required some level of scripting, it felt better to control the whole flow.  Also, none of them seemed to address my core problem.

Release Process:

Each workspace is represented by a stage in the release pipeline, and has the pertinent variables: workspace name, applicationId, client secret, etc.  The build artifact contains the PBIX files, separated by folders for datasets and reports.

I am able to publish the dataset successfully using New-PowerBIReport, without any duplication issue.  After publishing the dataset, I use the REST APIs to:

• "Default.TakeOver"
• "Default.UpdateDatasource"
• Update SQL Credentials
• Refresh the Dataset

Next, I publish all of the report PBIX files, also using New-PowerBIReport and use the REST API to Rebind the report to the dataset I previously published.

When this executes on an empty workspace, everything looks great.  However, subsequent executions of the release pipeline yield a copy of the report for each deployment execution: 5 deployments, 5 copies of the report.

I was able to determine on each subsequent execution of New-PowerBIReport that the datasetid associated with the file being published was different than the one previously published and rebound to the correct dataset.  I suspect this is the root of my issue, but not sure how resolve this.  As I stated earlier, I could delete the previous instance of the report, but this would produce a new set of report ids.  These Ids are currently being used by the process that displays the embedded reports.

If you made it this far, I sincerely thank you for reading my post and would appreciate your suggestions. 🙂

[V-lianl-msft]

Hi @jonesb321 ,

Maybe I don't fully understand your intention, template application could meet your needs.

Try to publish a template app and use it.

https://docs.microsoft.com/en-us/power-bi/connect-data/service-template-apps-overview 

Best Regards,
Liang
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[jonesb321]

Thanks for the suggestion.  This prompted me to do a little more digging into the Template Apps solution, but I'm not sure it will satisfy our needs.  While this is for an ISV type deployment, it is highly predicated on being provided as embedded content within the product.  Also, it appears template apps only support Direct Query mode, and we are currently working with Imported data.  If I'm overlooking something, please let me know.

I do see that the Power BI Deployment Pipelines seem to handle this, but not at scale.  They offer a metadata only deployment of the model, but I don't see where that is an option outside of the Deployment Pipelines solution.  I suspect if I could perform a metadata deployment of my model, then I should be good to go.