Forum Discussion
Deployment pipeline: Selective deployment via API
I am using the Fabric API to deploy content via a deployment pipeline.
https://learn.microsoft.com/en-us/rest/api/fabric/core/deployment-pipelines/deploy-stage-content
There is an option to deploy a subset of reports/semantic models if you provide a list of those items (rather than deploying all workspace items). My question: is there some way to identify the items that are new or different between the source and target workspace so that I can then deploy only the changed items?
Thanks for any advice.
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.
9 Replies
Hi kdoherty I would like to think that internally MSFT has already an API interface like "getDifferencesBetweenWorkspaces" or something, and I think internally becuase there is not something like open to the Public, so, I'm not offering a solution, but a possible approach.
if I were you and this would be just to critical that justifies my time & effort to implement, I will call first the API interface Items - List Items to get all the items within your source workspace, and then, call API interface Items - Get Item Definition and get the defintiion for each item in the workspace and then, do the same with the target workspace List items > For each Item Get Definition and compare source vs target JSON files! Taking in cosideration that the .platform are expected to be different just because of different Id's, among a big list of thing to consider.
In conclusion:
#1. Is there an API interface that gives you that? - No (perhaps it will be a good idea, to register as an Idea 😅💡)
#2. Is it's possible with current API intrerfaces? - Yes, but requieres some heavy coding.
#3. Would the benefit to do this outwages the work required? - Entirely up to you 😊
If you find another way, DO LET ME KNOW! I would be so interested in knowing how! For the time being, wish you best of lucks and hope at least this gives you some new ideas. A thumb's up for this info would be nice and even better if you mark as solution. Cheers.
Thanks for taking the time to respond. I appreciate it.
Hi kdoherty , Hope you're doing okay! May we know if it worked for you, or are you still experiencing difficulties? Let us know — your feedback can really help others in the same situation.
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.
