Salesforce - How to Deploy between Environments (Sandboxes, Live etc)

Question

We\'re looking into setting up a proper deployment process.

From what I\'ve read there seems to be 4 methods of doing this.

1. Copy & Paste -- We don\'t w

Answer 1

In any Salesforce production deployment, the Metadata API is one of the better options to do it. There are tools that simplify the work. Check out this post : https://www.deploypkg.com/deploy-to-production/

Answer 2

Another option is to use Change Sets if you want to move meta data from a sandbox to production.

There are currently some limitations on how change sets can be used:

Sending a change set between two organizations requires a deployment connection. Currently, change sets can only be sent between organizations that are affiliated with a production organization, for example, a production organization and a sandbox, or two sandboxes created from the same organization.

Answer 3

As of Spring '09, mail merge templates are not supported in metadata but record types are. You will find record types as an XML element in the file for the object they belong to. Everything else on your list is supported with a small exception. Picklist values for standard fields cannot be edited in Spring '09. Stay tuned for news on Summer '09 feature announcements.

Update: Standard picklists on standard objects are now metadata exposed (as of API v16): http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm

Otherwise, Steve Lane's response is pretty accurate. The advantage of using unmanaged packages (what Steve calls non-installed packages) is that when you add metadata to a package, the metadata it depends on will automatically be added. So it's easier to grab a full set of metadata containing all its dependencies. If you are repeatedly moving metadata from one org (sandbox) to another (production), Steve's approach is probably the best way to go and certainly the most common today. I frequently use unmanaged "developer" packages to move something I've developed in one org to another unrelated org. For my purpose, I like to have the package defined in the org as opposed to an Eclipse project / SVN. But that probably doesn't make sense if you are doing team development across many dev/sandbox orgs and are using SVN already.

Jesper

Answer 4

I'm still struggling with this myself. Neither the IDE of the Migration Tool have solved the main issues I face, which are as follows:

1. Installed packages cannot be deployed to a Developer Org. You have to install them manually one by one in the Dev Org.

   If a package cannot be installed in the org (for example because it requires password, like Marketo Sales Insight, or because it has been deprecated, like Salesforce for Google Adwords) and our application has dependencies on it (like references to fields in objects that belong to the package) then we won't be able to deploy the app.

   Workaround: if a package cannot be manually installed in a DEv Org each developer will need his own Developer Sandbox. Additional Developer Sandboxes can be ordered from Salesforce. (The client has to be willing to pay for them, though...)

2. When the sandbox is refreshed from production and we refresh our local project (which is connected to SVN) from the server all additional files/code that was in in the old Sandbox but it's not in production is going to be moved to the new Sandbox.

   Workaround: all changes made in production must be replicated in the Sandbox and the Developer Orgs. (Kind of a pain, but ok...)

Answer 5

I recommend the Force.com Migration Tool.

For reference:

• Force.com Migration Tool Documentation
• Migration Tool Guide

The Migration Tool allows you to use ant targets to move your metadata between salesforce.com organzations.

Answer 6

From the docs:

A package must be managed for it to be published publicly on AppExchange, and for it to support upgrades. An organization can create a single managed package that can be downloaded and installed by many different organizations. They differ from unmanaged packages in that some components are locked, allowing the managed package to be upgraded later. Unmanaged packages do not include locked components and cannot be upgraded. In addition, managed packages obfuscate certain components (like Apex) on subscribing organizations, so as to protect the intellectual property of the developer.

Advantage to managed package would be that it allows you to easily version and distribute things across multiple SFDC organizations.