A typical development process requires building, testing, and staging before releasing to a production environment. During this development cycle, one might migrate many times, either to keep development organizations in sync or to move changes through development organizations toward production and this is what we call Salesforce deployment.
Salesforce deployment is the migration of metadata from one Salesforce organization to another. If you are looking to enhance your Salesforce DevOps (Continuous Integration and Continuous Deployments) practices, this blog could get you started with the basics.
There are number of deployment tools available each having its own pros and cons. Some of them are listed below:
The simplest way to send configuration changes from one Salesforce organization to another, is to use a change set. It is usually used for a small number of component migrations. To send customizations from one org to another org, an outbound change set is created. The target (receiving) org sees it as an inbound change set. Sending an outbound change set to another organization doesnâ€™t implement the changes in that organization. The change set must be deployed by the target organization before the changes take effect. A change is deployed in a single transaction. If the deployment is unable to complete for any reason, the entire transaction will be rolled back. After a deployment completes successfully, all changes are committed to org and the deployment cannot be rolled back.Pros:
- Point-and-click tool (declarative deployment).
- Dependencies can be easily added with a single click.
- Migration among connected Salesforce organization only (like Developer Sandbox to Test Sandbox & Test Sandbox to Production organization etc.). Cannot be used in between any individual Salesforce organization.
- Doesnâ€™t allow destructive changes.
Ant migration tool (Force.com migration tool)
The Ant Migration Tool is a Java- and Ant-based command-line utility forÂ downloading metadata from one organization and storing it in a local directory. One can also deploy metadata from a local directory to different Salesforce organizations. TheÂ Ant Migration ToolÂ provides aÂ scriptedÂ way to deploy or retrieve metadata to and from a Salesforce org. One can also delete components from Salesforce org using this command-line utility.Â The Ant migration toolkit is often used in conjunction with a build server and source control to enable continuous integration. Itâ€™s built and maintained by Salesforce directly.
- Manual editing of XML files is required, which increases time overhead and possibilitiesor errors.
- All dependencies must be manually added.
The Force.com IDE is built on top of the open-source Eclipse Platform.Â The Force.com IDE is an integrated development environment for developing applications on the Salesforce Platform by using Apex, Visualforce, and other metadata components and is available as a plug-in in Eclipse. Using this tool, one can also compile and test the code, synchronize changes in a sandbox, and deploy metadata components from one Salesforce organization to another, or validate a planned deployment without saving changes. The Force.com IDE provides the Deploy to Server wizard for the deployment process.
- There is no deployment connection required, which means one can deploy the components from one organization toÂ any Salesforce organization. Â This tool can synchronize changes between any Salesforce organizations.
- Profile along with FLS is deployable.
- All dependencies should be manually added.
- Does allow destructive changes, but the process is quite tedious.
Deployments can be monitored on the Deployment Status page which lists all deployments- change sets, Metadata API-based deployments, including deployments started from the Force.com IDE and the Ant Migration Tool, and package installations.
To track the status of deployments that are in progress or have completed in the last 30 days, search for Deployment Setup from Setup.
Deployment can be cancelled while itâ€™s in progress or in the queue by clicking Cancel next to the deployment. The deployment, then has the statusÂ Cancel RequestedÂ until the deployment is completely cancelled. A cancelled deployment is listed in the Failed section.
Deploying from one Salesforce org to another is always challenging, time-consuming and requires substantial effort. As one can see, each of the above-mentioned Salesforce deployment tools has its own pros and con and using the right tool could ensure a faster and more reliable deployment process.