6

Is there currently any way to reset a salesforce development org to an empty state using the Migration tool. I am aware of destructiveChanges.xml but this seems to be giving me issues because of dependencies between the salesforce types.

Ex. Visualforce page referencing a custom object will throw an error when attempting to purge/undeploy the org.

Any suggestions would be greatly appreciated.

Improve this question
2

1 Answer 1

Reset to default
9

The migration tool doesn't provide this functionality directly, but it can be built on top of the migration tool. We've built and open sourced our build and automation scripts used at the Salesforce Foundation at https://github.com/SalesforceFoundation/CumulusCI

Assuming you already have a repository with your metadata contained in the src directory, you can reuse those build scripts in your own project quite easily (I'd recommend doing this in a feature branch):

  1. Clone the CumulusCI repository
  2. Set CUMULUSCI_PATH environment variable to point to the CumulusCI repository
  3. Copy $CUMULUSCI_PATH/template/* to the root of your project
  4. Edit cumulusci.properties and set cumulusci.package.name to the name you want to call your package.
  5. Regenerate your src/package.xml by running ant updatePackageXml which crawls through the metadata in src and constructs a package.xml that will deploy into a package in your org.
  6. Run ant deployWithoutTest
  7. To delete, run ant uninstall which retrieves all metadata from the package, builds a destructiveChanges.xml file to delete it all, then deploys the destructiveChanges.xml

Our build scripts are setup to handle many of the common metadata types we've encountered thus far but not every metadata type. If your project uses metadata the build scripts don't support, it's pretty easy to add the mappings in ci/cumulusci.xml and submit a pull request to add support.

We use what I refer to as Local Unmanaged Packages inside every org as a container for metadata in the org, but not for distribution from org to org. The advantage of using unmanaged packages as containers like this is that you can retrieve only the metadata in the package which makes building a destructiveChanges.xml much easier. Basically, you deploy your code into a container, then clear out the entire container.

One exception is RecordTypes which we do not attempt to delete through the destructiveChanges.xml as they cause errors that you can't delete RecordTypes through the metadata api.

There's also a ton more the build scripts provide but those are beyond the scope of the question. If you want to learn more about them, check out these two sessions I did at Dreamforce:

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .