function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
gokubigokubi 

Undeploying Apex code

I have successfully deployed Apex code from a Dev instance to a production instance. I noticed that when I go to the classes and triggers in the admin interface of my production instance, there are no delete buttons, and I can't deactivate the trigger.

Let's say that I don't want the Apex in my instance any more. If I wanted to "undeploy" this code, that is remove it or inactivate the triggers, what's the best way to do that?

In the deploy wizard in Eclipse, my triggers and classes are recognized, but I can't take any action with ones that are currently already deployed since I haven't changed the files. I see the triggers and classes in Eclipse of my production org, and there is a delete option in the context menu, but I'm afraid to attempt that for screwing things up royally.

Any guidance on undeploying would be appreciated.

Thanks!

Steve
mtbclimbermtbclimber
Deletion or de-activation of deployed code would make your tests invalid and thus subsequent deployments of separate functionality would be blocked and it might be difficult to figure out why certain tests are failing.

To undeploy code you need to go through the deployment process and specify deletion of the appropriate code and update of the classes containing the relevant tests.

You can, of course do a non-committing deployment to make sure your deployment plan is valid according to your current tests.

In short, you should make these changes in a development environment just as you would an additive change and once you are set with the changes go through the deployment process. Do the validation of the deployment plan as desired.
gokubigokubi
Thanks for that explanation, Andrew.

I'm a consultant and am looking to roll out the same base Apex code to each customer. Sounds like I'll have to install my apex code in a dev instance for each customer and then deploy from that to the production instance.

In my use case, that's a lot of moving code, moving customizations, etc. I can see how authoring Apex in a dev account first and deploying it to production is a best practice, but it's a bit onerous to force that on the developer, I think. I would like a bit more flexibility--the inability to effectively deploy from one location to many orgs is a drag, as is the fact that triggers can't be turned off in the production org. There may be a time during mass import where it makes sense to turn off the triggers for a few minutes.

Thanks for all the help filling in the gaps in the documentation! You're input is incredibly helpful to us trying to get our heads around all the pieces of the Apex puzzle.

Steve
jgrenfelljgrenfell
Steve,

For what you're looking to do, you may want to look into using Ant to deploy the code.  I actually hit some errors when I first tried to deploy with Eclipse, so was forced to use Ant, but it worked out because it actually has some useful functionality.  The code is deployed from the computer that's running Ant, not from the development environment, so as long as your triggers/classes successfully run all the unit tests, you could deploy the code directly to your clients' production environments. 

Also, Ant gives the ability to delete triggers and classes.  Any deployment to production, including one that deletes code, runs all unit tests and won't complete unless you have full code coverage and the tests run successfully, so you shouldn't have to worry about breaking anything by accident.

And one hacky method I used when I hit a problem doing a mass import was to surround everything in the trigger with an If statement so my code would only be executed if Trigger.new.size was less than 20 (or whatever number makes sense); that way I could import data but still have the triggers functioning for end users.  Not really recommended long term, but it was useful when I was importing historical data during business hours.

Jessie
steve_andersensteve_andersen
Thanks for the great ideas! I considered wrapping all my triggers with a conditional based on some data on a custom object, so we could just toggle a checkbox and turn off the triggers. Of course that burns a precious SOQL call, but only one per trigger. LIke your batch size conditional.

Steve
vermontvermont
Andrew wrote:
To undeploy code you need to go through the deployment process and specify deletion of the appropriate code and update of the classes containing the relevant tests.

How do you specify deletion? Do you just have to have to deploy an empty class or trigger file? Or do you use ant delete?

Page 221 of the reference guide:

12. To remove the test class and trigger added as part of the execution of ant deploy, enter the following in the command window: ant delete.
ant delete calls the Ant target named delete in the build.xml file.

<target name="delete">
<sf:compileAndTest
username="${sf.username}"
password="${sf.password}"
server="${sf.serverurl}"
apiversion="10.0">
<deleteClass>compileAndTest</deleteClass>
<deleteTrigger>phoneSetter</deleteTrigger>
</sf:compileAndTest>
</target>

For more information on compileAndTest, see Understanding compileAndTest on page 221.