Skip to main content

Salesforce - bypass running unnecessary unit tests during a deployment

We had to urgently fix a bug in an Apex class written by a previous colleague, which was causing major issues with a customer-facing application on a Friday afternoon (because these things always happen then).  We'd found the bug and updated the code easily enough, but Salesforce's default deployment option of running all local unit tests was failing because of some completely unrelated tests that were failing.

Salesforce's documentation (or at least the parts that I read) doesn't clarify that you aren't actually required to get 75% code coverage across all Apex code in your production org - you only need to get 75% coverage over the code you're deploying.  Here's how to do it and get that emergency fix into production asap.

You'll need the CLI for this, which you can easily install via chocolatey here.  You can probably do the same with the Salesforce DX CLI, but I'm used to this other one.

  1. Make a dev sandbox
  2. In production Salesforce deployment settings, select your new sandbox and ensure "Allow inbound changes" is enabled
  3. (in CLI) force login -i
  4. (in CLI) force export src
  5. Once the metadata export finishes, make the necessary code changes in /src/classes/
  6. Delete every directory in /src except for /classes
  7. Modify /src/package.xml by removing all the <types> nodes except the one for "ApexClass". This will make the import about a thousand times faster
  8. (in CLI) force import -directory=src
  9. Sometimes the import fails for no reason, try it again
  10. Create an "Outbound change set" in the dev sandbox containing only the classes you changed, and upload to production
  11. In production Salesforce, find the changes in "Inbound change sets", it should be in the "Change Sets Awaiting Deployment" section
  12. Important: Don't deploy the change set! Click "Validate" in the details page first
  13. Select "Run specified tests" and only enter the names of test classes that test only what's in the deployment
  14. Once they've passed, both the change set and the deployment should have a "Quick deploy" option.  Click that and you're done!


Popular posts from this blog

Using Log4Net to use both event log and a rolling log file

Here's the config section, note that the applicationNameproperty in the EventLogAppender needs to be the same as the event source in the windows event log that you want to log to.  If the event source doesn't exist, that appender won't work.  In this particular project I create that during install using WiX (which is covered in another post)

    <appendername="RollingLogFileAppender"type="log4net.Appender.RollingFileAppender">      <filevalue="log.txt" />      <datePatternvalue="dd-MM-yyyy" />      <appendToFilevalue="true" />      <locationinfovalue="false" />      <rollingStylevalue="Size" />      <maximumFileSizevalue="1MB" />      <maxSizeRollBackupsvalue="10" />      <staticLogFileNamevalue="true" />      <layouttype="log4net.Layout.PatternLayout">        <conv…

Using WiX to create an event source during install of a .NET framework project

Edit: so I guess I wasn't the only one confused with this stuff, as it's been my most popular post by far!  If I've helped you out or saved you some time, please let me know in the comments :)

In order for this to work, you have to add references to WixUtilExtension and WixNetFxExtension to your WiX project.  Once that's done, add this inside a <Component> element:

<Util:EventSourcexmlns:Util=""Name="EVENTSOURCEGOESHERE"Log="Application"EventMessageFile="[NETFRAMEWORK40FULLINSTALLROOTDIR]EventLogMessages.dll" />
Obviously replace EVENTSOURCEGOESHERE with your event source name.  NETFRAMEWORK40FULLINSTALLROOTDIR is a property set by the WixNetFxExtension which stores the path to the .NET framework v4 directory, but you can replace this with the corresponding property for the directory containing the relevant EventLogMessages.dll file.  So if you're using the .NET framewo…

How to make yourself a Dynamics CRM 2011 Deployment Administrator

Today I needed to deactivate one of our Dynamics organisations, but when I opened the Dynamics Deployment Manager, I received the following error:

"Only the Deployment Administrators are able to use Deployment Manager. You are not a Deployment Administrator."
Bummer. I did a bit of Googling and found this post by Ronald Lemmen (thanks for pointing me in the right direction!).  Since the Dynamics Deployment Manager is obviously checking the MSCRM_CONFIG database for this information I attached a database trace to it and found that it's executing these queries (among many others):

exec sp_executesql N'SELECT  Id, [DefaultOrganizationId], [IsDisabled], [Name]   FROM [SystemUser]   WHERE ((([Name] = @Name0)) ) AND (IsDeleted = 0) ', N'@Name0 nvarchar(41)',@Name0=N'{My windows domain account}'
exec sp_executesql N'SELECT  Id, [Name], [UniqueifierId]   FROM [SecurityRole]   WHERE ((([Name] = @Name0)) ) AND (IsDeleted = 0) ', N'@Name0 nvarchar…