Quick way to remove apex class from a production org

Published in Articles

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.

In order to delete apex class, you need to create a destructiveChanges.xml containing a list of classes that should be deleted.
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.

See Lifehack

Close

If you sure that all tests will be passed after deleting classes then you can choose "RunSpecifiedTests" option and set some random text to the "Run Tests" input. Please note that you cannot use "NoTestRun" when deploying to the production org, otherwise you will receive the "INVALID_OPERATION: testLevel of NoTestRun cannot be used in production organizations" error. Also, you cannot leave "Run Tests" empty, because you will see the next error "INVALID_OPERATION: runTests must not be empty when a testLevel of RunSpecifiedTests is used". So, if you don't wont to run tests during deploy process then you need to specify some random text like 'blah-blah-blah' in the "Run Tests" input.

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>



Useful links:

Comments powered by CComment