Tell me more ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.
up vote 4 down vote favorite

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?

share|improve this question

6 Answers

up vote 11 down vote accepted

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.

share|improve this answer
Thanks, @peter! The pro and con list is definitely helpful. – Mike Chale Aug 3 '12 at 19:32
@MikeChale, if you are happy with this answer, could you accept it? – Daniel Hoechst Aug 6 '12 at 14:45
1  
Re: Eclipse IDE - I've added Maven tasks in my IDE. You can use local task repositories even if you don't have JIRA and the option to change contexts easily when you work on several features in same time or just ctrl+click files in the context, right click, force.com -> deploy to server can be a real timesaver. – eyescream Dec 15 '12 at 9:20
up vote 2 down vote

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

share|improve this answer
Change sets are great! A couple of caveats: change sets work as long as the orgs are related. You can't send a change set from a Developer Edition org to a sandbox. Also, change sets can't do destructive changes. If you want to delete a metadata component you need to use the migration tool or the IDE. – Daniel Hoechst Aug 3 '12 at 17:20
Yes, I've used Change Sets for some things that I couldn't quite get with the Migration Tool. Other than creating packages, I'm hoping to find something more substantial/less manual. – Mike Chale Aug 3 '12 at 17:24
Change Sets don't show the full picture unfortunately. There is often many rows of configuration data, especially for custom Apps that can't be included in Change Sets, so you have to then import and export the data, which is a pain. – JodieM Aug 6 '12 at 3:59
up vote 2 down vote

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.

share|improve this answer
Hmm, I haven't tried that and will look into it. Thanks! – Mike Chale Aug 4 '12 at 12:01
What you want to do is go to the org from which you wish to migrate metadata and then simply browse to (or open a new tab) to workbench.developerforce.com and it will log you in to the workbench. – kadmin Aug 4 '12 at 17:36
Here is the FAQ about Workbench's metadata retrieve/deploy functionality: wiki.developerforce.com/page/Workbench#Metadata – ryanbrainard Aug 15 '12 at 18:05
up vote 2 down vote

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.

share|improve this answer
Upvoting for the idea of using Cases to help track changes. I'm surprised you say the IDE can't deploy workflow rules, though; those have metadata and the Migration Tool handles them with ease. – Mike Chale Aug 9 '12 at 11:38
up vote 0 down vote

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.

share|improve this answer
I've used this tool and it works. Is kinda slow and only works on Windows. Just some caveats that might sway your decision. – Amber Neill Aug 8 '12 at 20:22
Snapshot works with OSX also. Not so well all the time, but it can work. Try different browsers. – David Schach Sep 9 '12 at 4:40
up vote 0 down vote

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.

share|improve this answer
One can also verify/validate changes in production prior to pushing via the IDE. There's a Validate button. Not disagreeing with you; just pointing out that the functionality is not unique. – David Schach Sep 9 '12 at 4:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.