One of the most important parts of the Software Development Life Cycle (SDLC) is the the deployment process. In Salesforce, deployments aren’t really much more than copying metadata from one Salesforce organization to another. Salesforce has a few different deployment methods.
There’s basically two different situations that developers can be in that determine what deployment methods are available to them and which ones are the best for their situation.
Force.com / Eclipse
The Force.com IDE is a plugin for Eclipse which a lot of Salesforce developers use for developer. It can synchronizing changes between any Salesforce Orgs, but suffers from having a really terrible user experience. If there’s more than fifty or so components it basically hangs and crashes on windows.
The only time I like to use the Force.com IDE for deployments is when doing deletes of apex classes and test classes.
Change Sets have a really unique advantage that the other deployment methods don’t have. Using change sets, it’s possible to deploy the metadata without ever having to download the code to your computer. Change sets use a point and click tool to migrate metadata instead of using xml files or scripts. The process is relatively simple and for the most part it’s pretty painless.
It works like this:
- Connect two orgs together (Sandbox to Sandbox or Sandbox to Production.)
- Create an outbound change set by going through all of the orgs metadata.
- Upload the change set to the target org.
- Wait about 20 minutes or so, and click the Validate or Deploy button in the target org. I like to click the Validate button and do a Quick Deploy later.
I believe change sets are the simplest way of doing deployments, but it’s not without problems. The biggest disadvantage to change sets is that they aren’t available in some editions of Salesforce, for example developer orgs can’t use change sets. This may not seem like a huge problem, but this means that for Salesforce ISV’s it’s not possible to use them as they don’t normally have access to Sandboxes.
Force.com Migration Tool
The Force.com Migration Tool uses ANT and a custom jar file to allow us to update changes between any Salesforce Org that has access to the api. Basically, it works by moving metadata that is stored in a local directory to a Salesforce Org. It’s possible to script deployments because ant is a command line utility. The custom jar file I mentioned previously reads a package.xml file that is identical to what eclipse uses to download metadata.
The Force.com migration tool takes the longest time to setup, but I believe it’s usually the best option if your company is doing Continuous Integration and Continuous Deployment. It works very well with Jenkins, there’s even some plugins for it.
As developers, a lot of our time is spent getting things finally ready to deploy. I strongly recommend taking the time to learn more about the different deployment methods and seeing if something can work better for your company.
If you’re deployment process is slow, I’ve put together a list of some really good tips for Decreasing your Salesforce Deployment Time.