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

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

Pesticide

Answer 1

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.

Dominate

Thanks, I've looked into this, and it does seem the recommended way. Do you know if there's a way to deploy MailMerge templates using this tool? Thanks dan – Pesticide

"Force.com Migration Tool link" is dead – Phyfe

Answer 2

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

Kimi

Thanks for your reply. We ended up using the Eclipse based migration tool. Also looked into Ant, but for now Eclipse will do. Found that it sometimes fails because of dependencies but doesn't say what they are is annoying. – Pesticide

While packaging is painful, it is needed when developing for the AppExchange. In particular, if planning to support customers with Professional and/or Group edition. Without packaging, there is no way to create custom objects, run apex code, etc on these editions. Also, using managed packages allows you to segment your code from other developers. While writing unmanaged Apex code, there have been times when I had to write unit tests for previous developers in order to meet the code coverage requirements. – Diapedesis

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

Triceratops

How do you deploy your unmanaged package? I'm wondering if there is a way to deploy a package without having to re-select/list all the components as you do have to do with Eclipse or Ant... – Therapist

Answer 4

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.

Moriarty

Answer 5

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.

Tierza