Admins regularly use change sets to move changes from a sandbox to production. If you are deploying a couple of fields, workflow or validation rules, this process is quick and easy. But what happens if you need to move a more significant number of changes. Adding each component to a change set may take a long time. Even though you can use a View/Add Dependencies button a chance of missing something is still high. As a result, while working on bigger projects Admins often have to keep going back into a sandbox, adding missing components to change sets and deploying them again.
In my previous blog posts (‘How to Install Eclipse and Force.com IDE’ and Analyse and Update Profiles ) I briefly showed how you can deploy changes by using Eclipse and Force.com IDE. Today I am going to concentrate on deployment details, potential challenges that Admins face with more complex scenarios and ways of resolving them.
One of the company’s departments would like to start using Salesforce. A Salesforce Administrator gathered requirements, prepared a project scope and is ready to start building a solution. A list of customisations includes: creating new custom objects, tabs and fields, adding new validation rules and workflow rules with field updates and email alerts, modifying some of the existing fields, workflow and validation rules. Once configuration is completed in a sandbox and successfully tested, a Salesforce Administrator can move all the changes to production.
In this scenario no changes were made in production since the sandbox was last refreshed and project work started.
Once configuration changes have been completed in Salesforce Setup, create a new Force.com IDE project. You don’t have to include all metadata. Metadata is data that describes how your Salesforce org looks, feels and functions. You can see it when opening files of your Eclipse project. It will be sufficient to only include new and changed component groups. If you miss any, you can always add them later.
Then use ‘Deploy to Server’ functionality.
Right-click on ‘src’ folder of the project -> select Force.com -> Deploy to Server.
Add login details for your destination org, choose whether you are saving changes to production or to a sandbox and click Next.
In step 2 specify Archive location and click Next.
It is recommended to select both Archive options when deploying to production. Project Archive is a snapshot of the metadata you selected for deployment. Destination Archive is a snapshot of the metadata you are modifying in the destination org. It is useful to have this information in case you need to roll your changes back.
In Step 3 you can review which components you are deploying.
What I especially like is that as long as your project includes all ‘affected’ areas (remember, you can always include all metadata into a project if unsure) you don’t need to individually select each little change that you made. The system does it for you automatically. You will see ‘Add’ if you created something new (for example, an object or a workflow rule) or ‘Overwrite’ is they already exist in the destination org and you modified them. You can then untick those components that shouldn’t be deployed. If any metadata components are the same in both instances, you will see them in grey. They will be unticked by default.
Once a deployment process starts you will be able to monitor its progress and result (Success or Failure) in both Eclipse and Deployment Status area of your production org, just like you would see with a normal change set.
Due to a number of reasons a deployment may fail. The same thing can also happen to change sets, however, I find troubleshooting Eclipse deployments much easier than fixing failed change sets. If an Eclipse deployment fails, you will see a failure notification.
Expand it to see more details.
These error messages are quite descriptive and provide sufficient information for you to be able to fix the issues.
Troubleshooting a failed deployment
To be able to fix and ideally prevent deployment issues, you need to understand what can cause them. I am going to review them using a deployment from a sandbox to production as an example. When you deploy changes between two sandboxes, the principle is the same.
The most common reasons are:
- If you didn’t include some metadata dependencies into your project (for example added a workflow email alert but didn’t add a template) components may prevent you from deploying the customisations. If you are facing this issue, include missing components into your project and try again.
- Certain settings, for example, External Sharing Model, Entitlement Management, Salesforce Knowledge, Email-to-Case, etc. are enabled in your sandbox but not in production. Even if you create a project with all metadata and choose to deploy everything, such settings will not be automatically enabled in the destination org. To fix the issues you will need to manually enable them in the destination org.
- Your sandbox and production orgs are on different API versions. This is likely to happen when sandboxes have been moved to a new Salesforce release but production is still on an old one. In this case you need to check production API version (Setup-> App Setup -> Develop -> API ->Generate Partner WSDL -> find the words ‘API Version …’)
Open package.xml file of the Force.com IDE project you are trying to deploy and amend its API version to match.
Then try to deploy metadata again.
- Managed and unmanaged packages installed in production but not in a sandbox may conflict with new metadata and prevent you from deploying it. To resolve this issue, you either need to install such packages in the sandbox (a name of a package or its components will be referenced in error messages related to a failed deployment) or uninstall them in production. Most of the time you will install the package in a sandbox as uninstalling should be done with care to ensure nothing gets broken or no Salesforce users get affected.