I’ve been spending time lately trying to get a deployment pipeline to work for one of my clients and ran into a couple of non-intuitive limitations that I didn’t expect, so I thought they’d be worth a brief blog post.
- You can’t backfill previous stages if they’re not empty, i.e. you can’t deploy back from Test to Dev unless Dev is empty. In practice that means that you might have to delete all the entities in your Dev workspace if Test/Prod ends up having the latest version of your entities, then backfill Test. Not a great workflow in case you have any links (say from Teams) or automations (say from Power Automate) pointing to your test/dev reports.
- Deploying via the pipeline will only overwrite entities that were created via the pipeline. So if you created a dataset or report by publishing from Power BI Desktop without overwriting entities that were already there in the pipeline, this will create duplicates when you deploy to Test.
- Deploying a dataset deploys its metadata, not its data, so you’ll have to refresh it before its dependent reports show data.
- Because dashboards are weird artifacts whose definition can’t be saved as a file and because they’re typically created by end users rather than developers, they’re in a weird place where they’re orphaned in production without a way to easily sync them back to dev/test. Unless you can do it programmatically (haven’t checked) but this again highlights the awkwardness of the Test to Deploy being a rigid one-way street.
The main takeaway of all of this is that once you start using deployment pipelines, you need to be very consistent and diligent at working within the pipeline and not adding/deleting entities willy-nilly. It takes some time getting used to sticking to the process, going linearly from left to right. Always start pushing changes to Dev, not directly in Test. And push your model changes with ALM Toolkit, which you have to do anyway if you’re using incremental refresh.
One consequence of this linear pipeline structure is that I wouldn’t put in dev experiments and proofs of concepts that are not intended to be deployed anytime soon, if at all. Think of the Test workspace in your pipeline as your Beta workspace – Alpha versions don’t belong there.