Forum Discussion
Deployment pipeline: Selective deployment via API
Hi kdoherty , Thank you for reaching out to the Microsoft Community Forum.
Deployment pipelines in Microsoft Fabric do not have any built-in capability to detect what has changed between stages. The Deploy stage content API can deploy everything in the workspace or a list of item IDs that you explicitly provide, but Fabric itself does not expose any way to compare source and target stages, track versions or identify which reports or semantic models were modified. Because of this, pipelines behave as full promotion mechanisms rather than incremental ones. If you want to deploy only a single changed report, the pipeline has no way to determine that automatically, you must already know which items changed and pass only those item IDs to the deployment call.
In practice, this means selective deployment requires external change tracking, such as source control (PBIP + Git) or a release process that records which artifacts were modified. Without that external context, redeploying all items is the way of Fabric deployment pipelines today.
What are you hoping to achieve with this as it sounds like another orchestration method may be more suitable?
HI Kevin.
Thank you for the response. The goal is to deploy only the changed content to production. For example, in a workspace with 15 Power BI reports, we may make a change to only one. My understanding of Deployment Pipeliense is that by default all 15 reports will be re-deployed from (say) TEST to PROD using the deploy stage content endpoint. I would rather just deploy changed items between stages.
https://learn.microsoft.com/en-us/rest/api/fabric/core/deployment-pipelines/deploy-stage-content
Hi kdoherty , Thank you for reaching out to the Microsoft Community Forum.
Deployment pipelines in Microsoft Fabric do not have any built-in capability to detect what has changed between stages. The Deploy stage content API can deploy everything in the workspace or a list of item IDs that you explicitly provide, but Fabric itself does not expose any way to compare source and target stages, track versions or identify which reports or semantic models were modified. Because of this, pipelines behave as full promotion mechanisms rather than incremental ones. If you want to deploy only a single changed report, the pipeline has no way to determine that automatically, you must already know which items changed and pass only those item IDs to the deployment call.
In practice, this means selective deployment requires external change tracking, such as source control (PBIP + Git) or a release process that records which artifacts were modified. Without that external context, redeploying all items is the way of Fabric deployment pipelines today.
Thank you for explaining this so clearly.
