Have you ever deleted apex class from a production org? If so, then you probably know that it's not easy ☺
If you try to deploy deleted apex class using the change set, you will quickly realize that it’s not possible. But an apex class can always be deleted using an IDE, the Ant Migration Tool or the Workbench. In this article, consider deleting with Workbench, because, in my opinion, this is the easiest and fastest way that does not require any additional software.
I often use this method myself; therefore, in order not to "google" examples of destructiveChanges.xml and package.xml, first of all, I decided to write an article for myself.
Below you can see the sample of destructiveChanges.xml file, that specifies apex classes to delete:
<?xml version="1.0" encoding="utf-8"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata"> <types> <members>SampleApexClass</members> <members>SampleApexClassTest</members> <name>ApexClass</name> </types> </Package>
To deploy the destructive changes, you also need to have a package.xml file that lists no components to deploy, includes the API version, and is in the same directory as the destructiveChanges.xml:
<?xml version="1.0" encoding="UTF-8"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata"> <version>43.0</version> </Package>
Now that you have created these two files, they should be archived in a .zip file.
It's time to deploy our "change set" to a production org. To do this, go to the Workbench and log in with your credentials. On the login page, you should mark "I agree to the terms of service" and click on the "Login with Salesforce" button:
After successful authorization with Salesforce, click the Migration tab and select the Deploy option.
On the next page click the "Choose file option" and select our .zip archive and check the next options: "Rollback On Error", "Single Package". Test Level set to RunLocalTests and click on the "Next" button. Wait for the process to become completed. Please note, that "Rollback on Error" indicates whether any failure causes a complete rollback. This parameter must be set to true if you are deploying to a production org. The "Single Package" options indicate that the specified .zip file points to a directory structure with a single package.
As you can see, it's quite easy and fast to delete an apex class from production org. In this solution, the most costly is creating destructiveChanges.xml and package.xml files. I decided to simplify my life and yours, so at the end of the article, I added a dynamic form for quickly creating a .zip file. You only need to specify a list of classes and click "Create Zip" button. Enjoy!)
<?xml version="1.0" encoding="UTF-8"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata"> <types> <members><members> <name>ApexClass</name> </types> <types> <members><members> <name>ApexTrigger</name> </types> </Package>
Comments powered by CComment