Debugging Salesforce.com Deployments

Posted: 2013-11-01

One area that's always proven to be tricky in the Salesforce.com development cycle is doing deployments. Having seen quite a few questions on the Salesforce StackExchange on the topic, and having spent some time on a GotoMeeting call the other day helping someone work out a tricky deployment problem, it seems like a good idea to write down some key things to look for. This is by no means an exhaustive list so please submit your own pointers in the comments and I'll endeavour to add them.

Use a Friendly Tool

These days I'm using MavensMate to do manual deployments as it offers a few benefits over the Force.com IDE such as the ability to remember deployment credentials, saving you from entering every time you go through the process. The lack of such a feature in the Force.com IDE, combined with it's modal dialogs, really makes for a frustrating experience when things aren't going smoothly with a deployment.

Before Deploying

Before you even try to move anything to a new org, you should at the very least run through these three steps to be sure that you're in a good position to start with.

Run tests in the production org to ensure that everything is behaving there. If for some reason test coverage is below the 75% average before you start then you're more than likely in for a bad time. If coverage is below 75% then it must be because some tests are failing, so fix those issues before trying to deploy any new code (other than new test code!).
Goes without saying, but run your tests in your development org. If the coverage is lacking there, or worse, tests are failing, then you're not ready to deploy yet.
Run a diff tool over the two orgs. Using Eclipse, MavensMate or any other deployment tool it's easy enough to get local copies of all your code and object XML, and comparing the environments before you begin is a smart move. Look for differences in default field values etc. that could pose problems. Ideally there should be nothing in production that's not in your development environment; if there are new changes then move those to the development environment first to ensure compatibility.

When Tests Fail During Deployment

We've all been there; anxiously waiting for the tests to complete only to see the red cross of death appear, dashing our hopes and dreams for a quick, easy, move to production. Here are some pointers regarding what to look at when that occurs, and doing so will hopefully expedite the process of working out what went wrong and fixing it.

Ouch!

Check the logs! When deploying everything is logged and this should be your first port of call to see what went wrong; generally searching for 'exception' will help you find the issue but if the only failure is an Assert then it might not be so useful.
Do another diff between the two orgs and look for anything that could prevent data setup from working properly. Just the other day I had an issue where a default field value was different in production to the development org and that was enough to change expected results, causing some assertions to fail.
Once you know what's different between the two orgs, double check that you've included everything you need to. If you accidentally skip a component that you're updating then chances are your assertions will fail when the results of operations differ to those expected.
Make sure you're not using any hard coded IDs or relying on org data. Again, this goes without saying, but hardcoded IDs are going to cause problems, and should never be used; be it in tests or regular code.
This will not apply to every scenario, but if your new functionality depends on certain optional system features such as multi-currency support then make sure that functionality has been enabled for your production org!

What Else?

As indicated, this post is just a short list of things to check and look into when things go a bit wonky, but there's plenty of other issues that can cause even a simple deployment to grind to a hair-pulling halt. What else has caught you out before now?

Tips From Readers:

From Daniel Grossberg

If using change sets, you'll notice field level security, object access, record type, etc does not carry over to production unless the profiles are included on the change sets. My method includes migrating everything with the system admin profile, get everything working, then redeploy all custom fields, page layouts, record types, classes and pages WITH the profiles that need access.

Peter Churchill makes a great point here, it's far too easy for an administrator to inadvertently break tests in production!

The two places that always seem to cause me issue these days in deployments are Validation Rules, and Lookup Filters. Sooo easy to add in a live system, but cause havoc with test scripts etc. As such the cause of the failure can be a ways from the actual test since it was an issue with the test data creation...data factories can mitigate this, but alway a good place to look if you suddenly start seeing tests fail in live when they worked in test.