[SalesForce] Unable to use destructiveChanges.xml with multiple developers

(Sorry, long post)

We have a team of 4 developers, each with their own DE org

We are struggling with propagating destructive changes between orgs. From our reading of the docs, we should be able to document the fields that are being destroyed in destructiveChanges.xml and that change should propagate to other orgs when the Ant deployment task is run. This works in the extremely limited use case of the thing you're destroying not being referenced by any other source files.

I have created a very bare bones hello-world example at:

https://github.com/daveespo/forcedotcom-destructivechanges

The scenario goes like this:

  • Developer 1 commits a new SObject along with a VF page that references a new field on that object 5d07044
  • Developer 2 updates his working copy, does an 'ant deploy' and now both Developer 1 and Developer 2's orgs are in sync. Great.
  • Developer 1 decides that one of the fields isn't necessary, or that the name is misleading so he wants to remove/change it. Developer 1 makes the changes in his org (adding the new field, destroying the old field, and fixing up the reference in the VF page). Additionally, he documents the destruction in destructiveChanges.xml 51ce0575
  • Developer 2 syncs up his working copy and tries to do an 'ant deploy'. Boom! dead in the water.

Output from build:

Buildfile: C:\Users\esposito\Documents\xx\workspace2\forcedotcom-destructivechanges\build.xml

deploy:
[sf:deploy] Request for a deploy submitted successfully.
[sf:deploy] Request Id for the current deploy task: 04si00000012BLSAA2
[sf:deploy] Waiting for server to finish processing the request...
[sf:deploy] Request Status: Completed

BUILD FAILED
C:\Users\esposito\Documents\xx\workspace2\forcedotcom-destructivechanges\build.xml:12: FAILURES:
Error: objects/Spatula__c.object(Spatula__c.Color__c):This custom field is referenced elsewhere in salesforce.com. : Visualforce Page - Spatula.


Total time: 11 seconds

It appears as though the application of the destructiveChanges.xml and the updated source file(s) called out in package.xml isn't an atomic operation.

How do other teams work through this problem? The simple examples I've seen of destructiveChanges.xml don't address the problem of source files referencing 'to be deleted' objects called out in destructiveChanges.xml

The non-workable workaround is to commit 3 times — first, commit a change (breaking, of course) that dereferences the field to be destroyed, then commit a destructiveChanges.xml destroying the field, then commit the new field and restore all of the references to that new field. This requires the 'other team members' to very carefully sync up one commit at a time and apply them. Hardly friendly for devs that work on the project infrequently.

Best Answer

Bottom line is cleaning DE orgs is problematic at best.

You do need to list all of your components in the destructiveChanges.xml file unfortunately. The platform will not implicitly delete references nor let you ignore them. There are also some bugs / features even if you do reference all the components.

The solution we have found is to develop a 'dynamic' solution around this process. Which as you say seeks out references and clears them via a deploy. We have shared this, based on a Dreamforce 2012 presentation here.

undeploy : used to remove all metadata from the org.

usage: ant undeploy

Note: This requires a customised ant-salesforce.jar, vote now to have Salesforce support this properly.

Note: Related is the fact that the current Salesforce Ant tool does not pass on the 'purgeOnDelete' setting the underlying Metadata API takes, to effectively clear your waste bin of metadata. This is critical if you want to redeploy a new build. See this idea here to have this supported, until then a custom ant-salesforce.jar is needed.

Related Topic