Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

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

like image 846
danswain Avatar asked Feb 23 '09 11:02

danswain


People also ask

What are the different ways of deployment in Salesforce?

There are three deployment options in Salesforce: Change sets. Metadata API. Ant Migration Tool.

How do I connect two orgs for deployment in Salesforce?

Required Editions and User Permissions You can't create deployment connections between arbitrary orgs. Instead, you create connections between all orgs affiliated with a production org. For example, if you have a production org and two sandboxes, a deployment connection is created between production and each sandbox.


2 Answers

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.

like image 165
Ryan Guest Avatar answered Oct 25 '22 23:10

Ryan Guest


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

like image 35
slane7531 Avatar answered Oct 25 '22 23:10

slane7531