Learning Objectives

After completing this unit, you’ll be able to:

  • Choose the appropriate deployment tool depending on your scenario.
  • Know when to use managed and unmanaged packages in your organization.

Deployment Tools

You can use various tools to move metadata from one organization to another. It’s beyond the scope of this unit to teach how to set up and use each tool. However, at the end of this unit, you’ll have an understanding of the available tools, including the recommended tools to use. The Resources section at the end of this unit contains links to videos and documentation that provide more information about setting up and using those tools.

Change Sets and the Force.com Migration Tool are the recommended tools for migration. Change Sets is accessible through the Salesforce user interface and allows migrations between sandbox and production. The Force.com Migration Tool is a command-line tool and migrates data between two environments, including Developer Editions orgs.

The easiest way to move changes between a sandbox and a production environment is with a change set. For small deployments, the UI is easy to use, allowing you to select components and find dependencies. Because everything happens in the cloud, you don’t need to bring files to a local file system. You can also reuse a change set. After a change set is locked, you can deploy to all connected environments, secure in the knowledge that nothing can change. You can also clone a change set and make minor changes.

Tip

Tip

The Change Management module covers Change Sets.

The Force.com Migration Tool is a Java/Ant-based command-line utility for moving metadata between a local directory and a Salesforce org. Use the Force.com Migration Tool to perform repetitive deployments that can be scripted and that use the same components (the same package.xml file). For example, let’s say you make the same deployment to dev, test, and user acceptance testing (UAT) sandboxes and production. You want to be certain that the same components are deployed each time. The reliability of this tool makes it ideal for enterprise customers who are developing complex projects.

The following table compares both tools and provides examples of when it’s best to use each tool.

Tool Point & Click Scriptable Best for
Change Sets Check mark indicating true
  • Straight sandbox to production migrations
  • Change management without using a local file system
  • Auditing previously deployed changes
  • Enforcing code migration paths
  • Deploying the same components to multiple orgs
Force.com Migration Tool Check mark indicating true
  • Development projects for which you need to populate a test environment with a lot of setup changes—Making these changes using a web interface can take a long time.
  • Multistage release processes—A typical development process requires iterative building, testing, and staging before releasing to a production environment. Scripted retrieval and deployment of components can make this process much more efficient.
  • Repetitive deployment using the same parameters—You can retrieve all the metadata in your organization, make changes, and deploy a subset of components. If you need to repeat this process, it’s as simple as calling the same deployment target again.
  • When migrating from stage to production is done by IT—Anyone that prefers deploying in a scripting environment will find the Force.com Migration Tool a familiar process.
  • Scheduling batch deployments—You can schedule a deployment for midnight to not disrupt users. Or you can pull down changes to your Developer Edition org every day.

Learn about each tool’s considerations to better determine which tool is best suited for your needs.

Changes Set Considerations

  • You can move metadata only between the production org and its sandboxes. You can’t move changes between two production orgs or Developer Editions.
  • You can add components with a change set, but you can’t delete them. You must use another method to delete components, typically manually.
  • Because change sets are cloud-based, they’re not ideal when used with a source control system.

Force.com Migration Tool Considerations

  • Requires a more developer-oriented skill set, with experience of Ant and scripting tools
  • Requires storing the username and password on disk, which some security policies don’t permit

Other Deployment Tools and Artifacts

Besides Change Sets and the Force.com Migration Tool, you can use various tools for deployment. The following table compares some of the tools.

Tool Best For Limitations
Force.com IDE

Description:

Plug-in to Eclipse used for both development and deployment

  • Project-based development
  • Deployment to any org
  • Synchronizing changes
  • Selecting only the components you need
  • Some setup required
  • Not always upgraded at the same time as other Salesforce products
  • Repeatable deployments require re-selecting components, which can be time consuming and introduce errors
Force.com Workbench

Description:

Lightweight web-based tool that uses your local file system

  • Ad hoc queries
  • Deploy or retrieve components with a package.xml file
  • Metadata describes
  • Lightweight data loads
  • Not an officially supported product
  • No project management features
Force.com CLI

Description:

Command-line interface for Force.com APIs

  • Scripted commands and automated tasks
  • When your security policies dictate that passwords must not be stored on disk; forces interactive login
  • Logging in can be difficult behind a firewall

Deployment Artifacts

In addition to deployment tools, packages are another way to move metadata components from one org to another. However, packages are deployment artifacts and not deployment tools. The main use case of packages is for ISV developers to distribute apps to subscribers. But they can be used also for moving changes between Developer Edition orgs.

Artifact Best For Limitations
Unmanaged Packages

Description:

A collection of application components that can be distributed and installed in other orgs.

  • One-time setup of a development environment
  • A starting point configuration that can be customized
  • You cant’t make further changes to packaged components using subsequent packages
  • Requires a Developer Edition org
Managed Packages

Description:

A collection of application components with a namespace that can be distributed and installed in other orgs. Managed packages can be listed on the AppExchange and are upgradeable.

  • Commercial applications
  • Functionality you want to add in multiple, possibly non-related orgs
  • Access to code is limited or hidden
  • Unique namespace can be bothersome or a blocker
  • Difficult to modify or delete components
  • Requires a Developer Edition org
Share Time Estimate
Topics

Having trouble with your challenge verification?

Here are some tips:

  1. Check for typos (hey, it happens)
  2. Try using a new Developer Edition (existing customizations can interfere with the validation)