function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
ddddavoddddavo 

Help Needed: Making APEX patches in production

Hi all,

 

We all know that you shouldn't ever ever ever make code changes directly to production orgs.  The logical path is always to do your work in sandbox and push to production.

 

But what if you can't push to production, due to errors in code that are totally outside of your control?  Here's a scenario I bump into:

  • I deploy code
  • Later, client adds some code from other sources (AppExch, etc.)
  • Even later, client makes changes to picklists or adds validation rules
  • Now, the third party code always fails its tests...which means I can't deploy any code fixes I need to into the production org.
  • Which means we have to wait around for the thirt parties to stop finger-pointing and actually get their tests to execute without errors

In the good old days, there were ways you could edit code directly in the production org (the modules had to exist in the org already, but at least you could modify them) without running all the tests there.  So you could squeak by when there were emergency patches to be done.  But this doesn't appear to be true any more.

 

Of course, this situation should never happen.  But I've had it happen twice in a month at two separate clients.

 

Any ideas for work-arounds (assuming I'm using only tools that work on Windows)?  Isn't there a way to just "save" a file to production, without re-running all the tests?

bob_buzzardbob_buzzard

No way that I'm aware of I'm afraid.  Sometimes it seems to be possible around the upgade to new versions, but I doubt you can rely on that.  If there was a workaround (aka loophole!) it would be exploited to the max I'm sure, which would defeat the purpose of the production coverage requirements.

ddddavoddddavo

Well, there used to be a work-around for this that worked with the Force IDE.

 

There still is a work around that's out there, but it's a pain (no, I'm not going to give it away...so they don't close that loophole as well!)

 

How do people handle this situation, where somebody else's test errors are getting in the way of pushing a patch?

 

 

 

 

bob_buzzardbob_buzzard

We either direct our customers to the managed package suppliers and get the unit tests fixed, or advise them to disable the rule/required field etc that is breaking it for the duration of the deployment.  That said, we use tools such as cruise control or jenkins to execute unit tests on a nightly basis, so we tend to be able to pick up when things get broken early.