What is the achilles heel of changesets for you? What bugs you the most about change sets?
closed as off-topic by Matt Lacey♦ Feb 7 '15 at 6:16
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Question that are intended to propose ideas, solicit opinion or provoke discussion are better asked in an alternative forum." – Matt Lacey
Outside of personal preference (I find them to be cumbersome), I have two reasons I stay away from them.
First, when deploying custom fields, by default nobody has access, requiring that you take a second step to manually configure the access, resulting a greater opportunity to miss a step.
But the biggest issue I have encountered, is more related to the interface and the mindset of the people that put them together. I have seen too many pieces being forgotten, resulting in multiple changesets.
I am sure people with argue that you can get the same situation with IDE Deployment packages, but in my experience, the steps to building a changeset seem to encourage incompleteness.
I wish change sets were more like version control:
They would be much more useful if they merged changes from different source orgs into one target org, rather than simply overwriting changes of the first change set. It'd be even greater if they supported functionalities like branching/reversing commits.
I wish I did not have to specify changes down to the field level. I'd prefer to select an object and have every change on that object get transferred without having to list each one specifically.