We have a scenario where CI would be useful, but there is a risk of it making destructive changes...

Orgs in involved are Prod, UAT, Dev.

Ideal development path would be Dev->UAT->Prod with each deployment using Gearset.

In the real world, admins make some changes directly in Prod. So, we also need to merge changes back from Prod->UAT to make sure that UAT is a realistic test environment.

It would be great if we could make a CI connection from Prod->UAT which automatically deploys non-destructive changes, and notifies us if a change cannot be sent to UAT for risk of destroying something that has come in from Dev->UAT.

It seems like there are a couple of potential options for detecting what might be destructive...

1. If we are using Gearset to do all the deployments Dev->UAT, then when a potential CI job from Prod->UAT is going to overwrite something that we know from the deployment history to have come from Dev but not been sent to Prod, then this would count as a potentially destructive change.

2.If the last modified date of the metadata item in UAT is newer than the last time that element was update by a CI job from Prod->UAT, then the change would count as a potentially destructive.