Salesforce Deployment Process and Common Errors

In our last article, we introduced what it takes to prepare a successful release strategy.  We all want to have the perfect, airtight release plan, but a real Salesforce Hero knows that sometimes unfortunate things can happen despite our best efforts. In these cases, it can be helpful to understand how exactly Salesforce’s deployment process works, as well as some common issues to expect, so that we can calmly handle any unexpected events that may be thrown at us.

Deployment Methods

There are a number of ways that you can move your Salesforce metadata from one org to another including:

• Change Sets
• Ant Migration Tool
• Metadata API

In this article we will focus on Salesforce’s out of box deployment process which uses change sets.

How the Salesforce Deployment Process Works

The three major steps in performing a deployment are

1. Activate a deployment connection
2. Create and upload an outbound changeset
3. Deploy the inbound changeset in the receiving org

Deployment Connections

You need to have an active deployment connection to send a change set from one org to another. You have to individually set whether each org is authorized to receive change sets from another specific org. This allows you to have policies that define specific promotion paths from sandboxes leading up to your production org. Authorizing an org to allow inbound changes can be done by navigating to Deployment Settings in Setup, clicking edit on the org you want to authorize and then checking the box for Allow Inbound Changes.

Create and Upload an Outbound Change Set

Change sets can be created through the Salesforce UI in the setup. (This requires the Create and Upload Change Sets permission). Depending on the number of the changes you are trying to deploy, this can be quite a cumbersome process, so it is important to know what to expect and some best practices.

Change sets can only contain metadata and configuration changes for your org. They do not contain data such as records.

Validate and Deploy an Inbound Changeset

Once a change set has successfully been uploaded, it appears in the destination org as an inbound change set. You have the option to Validate, Deploy or Delete the change set. Validating a change set allows you to run tests and view error or success messages without committing the changes to your org. When a change set is validated, it can be available for a quick deployment, which allows you to deploy the changes without needing to run Apex tests again, so it is usually worth it to validate your changes first.

Change sets are deployed in a single transaction. This means that if any error occurs during the deployment process, the entire deployment fails and is rolled back. This can be quite frustrating at times, but also ensures that you do not have bits and pieces of functionality in your Production org when everything isn’t ready yet.

Deployment Errors

You think you have everything ready, and you eagerly click the deploy button. Just as you start to imagine how much your users will enjoy your awesome new functionality, an error message pops up on the screen! Don’t panic! Here are a few deployment errors that we run into and how to fix them.

Test Class Failure

Salesforce requires that at least 75% of Apex code is covered by unit tests and that those tests pass. If even one test method is unsuccessful during the validation step, the deployment fails. Always make sure to thoroughly test your code and make sure you have enough code coverage before your deployment. If you still experience errors, some common things to look out for that could be the cause are new fields, dependencies, or validation rules that were created directly in your Production org.

Missing Components

This is another very common issue. Sometimes you just forget to include an item like a field, page layout or even helper Apex class that other components in the change set are dependent on. This is a very simple issue to resolve, but can get quite tedious since change sets cannot be edited once they are uploaded. You will have to clone the change set and add the missing components to the newly cloned change set. Creating 10 different versions of the same changeset can be avoided by following pre-deployment best practices like keeping a running list of deployable items during development, and clicking the “Check Dependencies” button that Salesforce provides while building the changeset to see if there’s anything you missed.

Dependent Class is Invalid and Needs Recompilation

Sometimes, Apex classes and triggers get flagged as invalid because dependent metadata such as object or field names referenced by the class were changed. This error can also occur if changes are made to a class that calls the class you are trying to deploy. If you get this error, you can try compiling all the custom code in the org. This can be done by navigating to Apex Classes or Apex Triggers in Setup and clicking the “Compile all classes” or “Compile or triggers” link respectively.

Conclusion

Deployments can be daunting at first, but with proper preparation and a clear, careful strategy there should be nothing to fear. Errors and obstacles are bound to appear every once in a while (hey, you’re only human!), but by staying organized and keeping the above points in mind you should be swimming in deployment fish in no time!

If you would like to learn more, or prefer to have seasoned experts handling your Salesforce development and deployments, consider contacting us for a free consultation. Upsource is always happy to help our customers win big!