Salesforce - How to Deploy between Environments (S

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 want to do this
2. Using the "Package" mechanism built into the Salesforce Web Interface
3. Eclipse Force IDE "Deploy to Server" option
4. Ant Script (haven't tried this one yet)

Does anyone have advice on the limitation of the various methods .

Can you include everything in a Web Interface package?

We're looking to deploy the following items:

• Apex Classes

• Apex Triggers

• WorkFlows

• Email Templates

• MailMerge Templates -- Can't seem to find these in Eclipse

• Custom Fields

• Page Layout

• RecordTypes (can't seem to find these in Website or Eclipse)

• PickList items?

• SControls

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

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 3

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 4

I can speak to this from recent painful experience.

Packaging: this is a very old method that predates the metadata API on which both Ant and Eclipse rely. In our experience, packaging's only benefit is in defining your project. If you're using Eclipse (which we do, and I recommend), you can define your project as being based on a particular package. As long as you remember to add new components to your package, your project hangs together

One thing that baffled us for a while, btw, are the many uses of package. We've noted the following:

Installed packages: these come in managed and unmanaged flavors and are really, in the words of a recent post on the SFDC boards, for ISVs to deploy their stuff into various unknown orgs "out there". Both managed and unmanaged packages have limitations that make them unsuitable and unneeded for deployment from development to production within an org, or in any case where you're doing custom development and don't intend to distribute code to a large anonymous base.

Non-installed packages: this is what you see when you click "Packages" in the web UI. These, that we sometimes call "development packages", seem to be just a convenient way to keep a project definition together.

Anyway, the conclusion I'm coming toward is that our team (custom development, not an ISV) does not need packages in any form.

The other forms of deployment, both Eclipse and Ant, rely on the Metadata API. In theory they are capable of exactly the same things. In reality they appear to be complementary. The Force.com migration tool, built into the Force.com IDE for Eclipse, makes deployment as easy as it can be (which is not very) and gives you a nice look at what it intends to deploy. On the other hand, we've seen Ant do some things the IDE could not. So it's probably worthwhile to learn both.

The process we're leaning toward is to keep all our projects in SVN, and use the SVN structure as the project definition (Eclipse will work with this and respect it). And we use Eclipse and sometimes Ant for migration. No apparent need for packages anywhere.

By the way, one more thing to be aware of -- not all components are migratable. Some things must be reconfigured by hand in the target environment. One example would be time-based workflows. Queues and Groups also need to behand-created, I think. Likewise the metadata API can't directly process field deletions so if you deleted a field in your source, you need to delete it by hand in the target. There are other cases as well.

Hope that's useful --

-- Steve Lane

Answer 5

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 6

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