What are the most effective and efficient ways to manage objects, fields and workflows? Our setup involves one developer sandbox to try out ideas, a QA sandbox to validate changes, and the our production org. I'm currently using the Force.com Migration Tool and associated XML files, but they can easily get out of date and not everything is metadata driven.

What other options exist and are recommended?

Attribution to: Mike Chale

Possible Suggestion/Solution #1

We use Change Sets. I'll add a PRO to Peter's list

• Ability to verify/validate changes in production prior to release.

We use this for every release (Dev and Config) and have had no issues with it.

Attribution to: Jason Faulconer

Possible Suggestion/Solution #2

Do you know about Change Sets? They allow you to move code, objects, fields, triggers, page layouts, profiles, etc.... from one sandbox to another or to production. There is a full validation process as well.

They will change your life.

http://www.youtube.com/watch?v=EvwMfflh5LE

Attribution to: Wes

Possible Suggestion/Solution #3

Here are some of the pros and cons that I can think of off the top of my head. YMMV.

Change Sets

Pros:

1. Ability to keep a running set of changes that were made (unlike the Force.com IDE)

Cons:

1. Very manual, and therefore, error prone.
2. Slow UI. Can't sort on last modified date, for example.
3. Can't tell what was actually changed (have to manually keep track elsewhere or use the Audit log)
4. Removing from the change set must be done on a single item by item basis.
5. Doesn't support as many components as the Force.com IDE or migration tool.

Conclusion: Best fit for very small sets of changes done by a single developer on an infrequent basis.

The Force.com IDE process

Pros:

1. Easy to see what has changed.
2. Can zip the source and destination prior to deployment.
3. Can synch up with a central repo (e.g., SVN), in theory.

Cons:

1. No ability to recall a previous configuration. This is a showstopper for large deployments. If you are working on a large project and it can take you 10+ minutes to build up your deployment (that isn't the problem, though). The issue is when that deployment fails your validation step, you have to exit out of the deployment UI to fix it, which loses it.

Conclusion: Best fit for small sets of changes, possibly by a team of developers.

Ant migration tool

Pros:

1. Scritable. This allows you to incorporate it within other processes. You can combine it with data loading scripts, continuous integration, etc. If there are data issues and/or certain components that don't deploy well (e.g., SF bug) you can set up scripts to parse/transform into an acceptable state.
2. Depending on how you have package.xml file(s) set up you might be able to make it less of a chore to update your scripts.

Cons:

1. May have to manually update XML files.

Conclusion: A decent amount of upfront work, but good for long running projects/maintenance.

Other As for your concern about not having support for everything in metadata, change sets actually support less components.

Attribution to: Peter Knolle

Possible Suggestion/Solution #4

There is a paid tool on the appexchange

I have never used it, and have no idea about it's suitability. But if you are looking for alternatives it could be something to consider.

Attribution to: Daniel Blackhall

Possible Suggestion/Solution #5

Another option to consider is Workbench (workbench.developerforce.com). This will allow you to build packages from your sandbox organization and upload to your QA/production org. The Workbench tool has a lot more functionality too. It is a combination of Apex Explorer, Apex Data Loader and Migration Tool.

Attribution to: kadmin

Possible Suggestion/Solution #6

I use two different items for my deploys.

I use the IDE with Eclipse for big deploys - especially when it involves Code.

I use ChangeSets for small deploys - or deploys that involve things like Workflow Rules.

Change Set are nice, but they can get bulky and time consuming with huge deploy setups. Plus not everything is included in Change Sets for Deploys.

The IDE is great, but you can't really deploy workflow rules (I haven't been successful at least). Plus it can be a bit slow especially if you lots of tests in the system.

My preference is to always go Dev sandbox -> Full copy QA Sandbox. Validate changes in QA Sandbox. Any changes happen in Dev and then redeployed. Then Dev Sandbox -> Production.

I don't use either the IDE or Change Sets to track actual changes. I use Cases in our production system to track what was getting change. The plus side is if the item has a description I can include a link to the case for future reference.

Attribution to: Salesforce Wizard
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/146