Salesforce Deployment Methods

Sharing is Caring

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. / Eclipse
The 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 IDE for deployments is when doing deletes of apex classes and test classes.

Change Sets
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:

  1. Connect two orgs together (Sandbox to Sandbox or Sandbox to Production.)
  2. Create an outbound change set by going through all of the orgs metadata.
  3. Upload the change set to the target org.
  4. 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. Migration Tool
The 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 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.

Sharing is Caring

Brian is a software architect and technology leader living in Niagara Falls with 13+ years of development experience. He is passionate about automation, business process re-engineering, and building a better tomorrow.

Brian is a proud father of four: two boys, and two girls and has been happily married to Crystal for more than ten years. From time to time, Brian may post about his faith, his family, and definitely about technology.


Comments are closed.