Understanding Change Sets Limits
Several years ago, I was working on a large Salesforce roll-out for a customer whose deployment policies were constraining the team to use change sets. It was a multi-sandbox, multi-vendors environments and change sets were not ideal, to say the least. As it happens, we ended up, for each version released to production, with several packages and 30+ pages of pre and post deployment manual steps. A real nightmare, still, it gave me the opportunity to push the method to its maximum and see through it.
If you're building a Salesforce solution making good use of standard objects and intend to ship all your configuration from sandbox to sandbox to production, get ready for a lot of manual work. Relying on manual rework generates the risk to build a great looking solution in DEV, get it somehow signed-off in UAT and then screw-up the migration to Production to deliver a non-functional product... Not what you're after!
These are the usual change sets issues:
- They only support a subset of Salesforce configuration components!
- They don't carry over deletions nor rename operations.
- They don't manage dependencies as well as Packages do.
- They can't be merged.
- They can't be reused in the destination org (by a different team).
- They have a complex relationship with Profiles and Permission Sets.
- The user interface sucks.
Deciding On Change Sets
It is difficult to assess in advance if change sets will let you ship your work or not.
This is because their limits are not clearly documented. The Metadata API Guide contains a list of Unsupported Metadata Types but this applies to the developers' deployment tools (Eclipse or ANT). Sadly, change sets are only using a part of this API. This means that some of the changes that can be packaged with ANT, for instance, can't be so with change sets.
Something had to be done to shed some light on the change sets feature gap. So, today, I'm launching a crowdsourced initiative to list all of the change set limits.
Following on the traces of Meighan Brodkey and Doug Ayers with their Features You Need to Contact Salesforce to Activate, I thought that getting the community to build a similar list for the change set limits would have the following benefits:
- Simplify the decision process around deployment tools.
- Start multiple conversations about blockers and their workarounds.
- Become a checklist for the Salesforce DX product team.
You can add your own comments directly on the Google Sheet.
Improving The UI
This should address the points 1 to 6 of the list of issues. For point 7, As far as the UI is concerned, I wouldn't wait on Salesforce. Sadly, there's way too much work to expect a quick fix.
@CherFeldman whoever built change sets never had to use them.— Keir Bowden (@bob_buzzard) December 9, 2016
I'd love to see Salesforce improving the Change Sets UI as soon as possible but I guess that DX is going to swallow all the specialised resources...
Related Posts & Resources
- Unsupported Metadata Types
- Special Behavior of Components in Packages
- Components Available in Change Sets
- Change Set Best Practices
- Change Sets Implementation Tips
- Deployment Checklist
- Trailhed - Change Management
- Development Lifecycle Guide
- Dude, Where's My Permission?
I hope you enjoyed this post. Don't hesitate to ping me on Twitter if you have any comment or question. Bye for now!