Forum Discussion

dbeavon3's avatar
dbeavon3
Memorable Member
3 years ago

Build and deployment pipelines for Azure Devops - problems with PBI DATAFLOWS

Some time ago we were given encouragement that Microsoft is starting to allow deployments from Azure Devops (ADO) to Power BI.  This provides us the ability to use is ADO features (work items, source control, build artifacts, versioning, and lots of actual ALM)

 

A contractor helped us to set up our ADO build pipelines, and our ADO release pipelines.  The implementation relies on standard REST interfaces, and powershell.  No custom extensions, or Microsoft extensions for ADO were used.


I was happy to see that DATASET deployments could be done easily, and could target as many different workspaces as needed (ie. preproduction environments).  However the REST-API-interface features that are provided by PBI for deploying dataflows are quite limited and poorly designed.  Here are the primary issues that we encountered:

 

  • Parameterization - unlike with datasets, with DATAFLOWS it is not possible to change the data source connectivity (connection strings) via parameters.  What we ended up doing is to create elaborate build pipelines to edit dataflow/json files before generating target-specific artificts (for dev, prod, etc).  
  • Authorization - unlike with datasets, the DATAFLOWS cannot be deployed from a DevOps release pipeline that runs as a service principal (ie. "service connection" in ADO).  As such, we must deploy datasets using one workflow and dataflows using another.

 

Has anyone else noticed the disparity between dataset and dataflow components?  Are there any easier ways to automate our ADO deployments?  Am I overlooking some tools?  (FYI, The consultants said that the "PBI release pipelines" were a non-starter for us since our requirements involve deploying to an odd number of preproduction workspaces.   I think the PBI release pipelines only support one or two workspaces).

 

Any help would be appreciated.  Hopefully there are more people out there who are starting to use ADO; and we aren't blazing a new trail. 

 

 

 

 

2 Replies