Using Destructivechanges.xml and force:source:deploy --ignorewarnings to Production Environment

Question

We are using Github as our source control and Drone.io CI/CD pipelines to handle builds and releases to multiple sandbox environments and our production environment. We would like to use destructivechangespre.xml and destructivechangespost.xml to reduce manual work related to each release.

I know that when you deploy a release that contains destructive changes a second time to an environment you will get errors related to not being able to delete the metadata components that are in your destructivechanges file(s) due to them not existing (since they were already deleted during the first deployment, of course). I've also heard that you can get around this issue by appending the --ignorewarnings tag to your deployment command.

My questions are:

1. Is it the --ignorewarnings tag that is appropriate to use for this case or --ignoreerrors?
2. Whichever tag will allow us to circumvent this warning/error, does it work when deploying to a Production environment?

Answer 1

Is it the --ignorewarnings tag that is appropriate to use for this case or --ignoreerrors?

Ignore Errors would be appropriate here. Warnings are things like Code Coverage problems.

Whichever tag will allow us to circumvent this warning/error, does it work when deploying to a Production environment?

No. You're not allowed to ignore problems or allow partial updates to production.

---

Your solution for CI/CD is to use Unlocked Packages. These are prevalidated and therefore won't have warnings or errors by the time you get to deploying to production. This will subsequently save you a lot of trouble in many cases. As a bonus, Unlocked Packages relieves you of the need for destructive changes, as the Mixed upgrade mode (the default) can delete unused elements and deprecate others, or you can even force deletion during package installation by specifying the Delete upgradetype.

If you haven't checked out Unlocked Packages yet, you might want to take a look.

Answer 2

I agree with @sfdcfox that Unlocked Packages is the way to go, but transitioning to Unlocked Packages is not an overnight journey.

In the meantime, we have found that the --ignorewarnings parameter does ignore the "already deleted" destructive changes message and have not found another reason to use this parameter in a deployment.

Whilst it can be used for ignoring code coverage warnings, that isn't a problem caused by the deployment process itself and so altering the process to resolve those warnings should be avoided. Similarly with --ignoreerrors, we've never found a valid reason to apply that in a deployment and have instead always gone back to the developer and fixed the metadata itself.