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?
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Here are some of the pros and cons that I can think of off the top of my head. YMMV.
- Ability to keep a running set of changes that were made (unlike the
- Very manual, and therefore, error prone.
- Slow UI. Can’t sort on last modified date, for example.
- Can’t tell what was actually changed (have to manually keep track elsewhere or use the Audit log)
- Removing from the change set must be done on a single item by item basis.
- 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
- Easy to see what has changed.
- Can zip the source and destination prior to deployment.
- Can synch up with a central repo (e.g., SVN), in theory.
- 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
- 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.
- 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.
- May have to manually update XML files.
Conclusion: A decent amount of upfront work, but good for long running projects/maintenance.
As for your concern about not having support for everything in metadata, change sets actually support less components.
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.
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.
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.
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.
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.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0