Items showing as Not in source and Only in source in deployment pipeline

[samkikibaker]

I have a deployment pipeline dev>uat>prod and I have already run the dev>uat deployment pipeline. However now when I try to deploy from uat>prod, every item is showing as both "Not in source" and "Only in source" (see screenshot). What is causing this and what can I do about it?

[burakkaragoz · Accepted solution]

Hi @samkikibaker ,

This issue typically occurs in Power BI deployment pipelines when the metadata between environments becomes unsynchronized. In your screenshot, you can see that the item is shown as both "Not in source" and "Only in source" when deploying from Test to Production. This usually means that the object exists in the target (Production), but the pipeline cannot find a matching reference in the source (Test), or vice versa.

What causes this?

1. The object may have been renamed, deleted, or recreated outside the deployment pipeline process (e.g., directly in the workspace).
2. There might be a mismatch in object IDs or metadata, especially if items were manually changed or replaced in one environment.
3. The pipeline may have lost track of lineage, commonly due to manual interventions.

How to fix it:

• Ensure that all deployments are performed through the deployment pipeline, not manually in the workspaces.
• If you made changes directly in Production or Test, try deleting the affected item in the target workspace and redeploying from the source.
• You can also try to remove the item from the deployment pipeline and add it back to resync the metadata.
• Make sure that object names and types are consistent across environments.

Steps to resolve:

1. Delete the problematic item (e.g., df_pipeline_bgrid_ingest) from the Production workspace.
2. Go back to the pipeline, and deploy again from Test to Production.
3. Verify that the item now appears correctly as "In source and target" in the deployment comparison.

If you continue to experience issues, double-check that no manual changes were made outside the pipeline and consider refreshing the deployment pipeline mapping.

Let me know if you need step-by-step guidance!

[samkikibaker]

Thank you so much for your detailed reply - I really appreciate it.

It's strange that it seems to be manual interventions which have lead to this issue. I didn't see this issue when I deployed from dev > uat and I've not modified the items in any way in the uat workspace. Could it be that the deployment pipeline edits the meta data of the items when they move from dev to uat? Or is there another reason for the metadata de-syncing.

It is happening for every item in my workspace (currently ~20 items). So is it a case of deleting every single one manually in production and then redeploying? This doesn't seem like it would a great solution as will lead to temporary outages so I'd be keen to hear how I can avoid this in future. 

[burakkaragoz]

Thank you for your follow-up and for providing more details.

You’re correct that ideally, you shouldn’t need to manually delete every item in Production, as this can be disruptive and is not an efficient long-term solution. The deployment pipeline is designed to handle metadata changes automatically, but sometimes, issues can occur if there are hidden differences or if the pipeline loses track of the lineage between environments.

Here are some recommendations to help avoid this problem in the future:

1. Always deploy using the pipeline:
Avoid making any manual changes (additions, deletions, or edits) in any environment that’s part of the pipeline, especially in UAT and Production. Even minor manual changes can break the lineage and cause metadata mismatches.

2. Check for hidden differences:
Sometimes, differences are not visible in the UI but exist in the metadata (e.g., parameters, permissions, or linked services). Try to keep environments as consistent as possible.

3. Workspace Cloning (if possible):
If this issue continues, consider creating a new Production workspace and deploying everything fresh from Dev > UAT > Production to restore correct lineage, especially if there are too many mismatches to fix manually.

4. Monitoring and Logging:
Regularly review the deployment pipeline’s logs and compare items after each deployment to catch issues early.

5. Raise a Microsoft Support Ticket:
If you’re following best practices and still seeing this issue, there could be a bug or undocumented limitation. In that case, reaching out to Microsoft Support with your pipeline details and error screenshots is recommended.

You shouldn’t have to manually delete items every time. Once lineage is broken, a one-time manual cleanup may be necessary, but after that, sticking strictly to the pipeline for all changes should prevent the issue from returning.

Let me know if you’d like a step-by-step guide or have more questions!