Apex Code Development You need to sign in to do that
Don't have an account?
Tommy Sunderland 16 Help: Trying to deactivate Apex Trigger, but change set fails during deployment
We're trying to do a mass import of Contacts using the Data Import Wizard (to prevent duplicates), but in doing so we had many errors because we hit governance limits due to an Apex Trigger. I have since deactivated the Apex Trigger in Sandbox by unchecking the "Is Active" checkbox and sent the deactivated Trigger via a change set to the Production Org, but when I try to deploy it in Production, I receive an error that one of the tests has failed (and therefore cannot deploy).
I'm looking for advice on the easiest/best way to deactivate
I've included screenshots of the Error Message that I get when trying to deploy below, as well as the original Apex Trigger code. I can send through actual code if needed.
Is it possible for you to comment out the Trigger body containing the code and redeploy? Moreover, during deployment you can choose which test classes you intend to run using the Run Specified Tests option which allows specifying the test classes you intend to run during deployment. Note: However, you excluding certain the classes may reduce the overall code coverage which may affect your deployment.
Additionally, just a workaround and NOT A BEST PRATICE. Comment out the assert statement within the respective Test class on the sandbox and deploy that, to avoid firing an assert failure in case you do not want to exclude the execution of the specific test class. Please do not use this mechanism since it is a risk and will not help you identify test code failures in case of code changes to existing Apex code in the long run.
Last but not the least it is imperative to review your org's test code coverage periodically so as the ensure that they meet the code coverage criteria with adequate asserts.
But as per best pratice try to update your trigger and make it bulky like below
1) remove SOQL from for loop
2) Update your SetAccountEmail and send list of account together.
As a best practice always try to use clicks before code. If there an out of box feature that helps you achieve the desired output use that instead of building a custom implementation using code.
The out of box features help you benefit with the advantages of shorter production release times and avoid the additional effort of writing test code to get the desired code coverage. Moreover, out of ox features are more maintainable in the long run with the advantage being able to deactivate them on production based on your need.
One thing you may want to check with the Porcess builder implementation is its ability handle bulk records since that aspect is pretty nascent and I see multiple queries around bulkificaiton of process builders. You may want to check that before taking the Process Builder route.