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 app in your Dev sandbox, get it somehow signed-off in the UAT sandbox and then screw-up the migration to Production delivering a non-functional product... Not what you're after!
These are the usual issues people find when deploying with change sets:
- They only support a subset of Salesforce configuration components.
- The user interface sucks.
- They look like a simple tool but come with many gotchas.
- They don't manage dependencies as well as Packages do.
- They have a complex relationship with Profiles and Permission Sets.
- They don't carry over deletions nor rename operations.
- They can't be reused in the destination org (by a different team).
- They can't be merged.
The Metadata API Guide contains a list of Unsupported Metadata Types but this only applies to the developers' tools like Eclipse or Ant. When deploying with Ant, I'm using the Quip Spreadsheet below to plan in advance the parts of the project that will require manual deployment work and measure the associated risk.
I'm narrowing down the list of 52 unsupported metadata types to the 8 in scope for my project (that's an example). This, in turn, enables me to focus the test team on these areas after a deployment. Sadly, you can't do that with change sets since the unsupported components are not documented. The only thing we know is that whatever can't be done with the API, can't be done with change sets either.
It is difficult to assess in advance if change sets will let you ship your work or not.
Something had to be done. So, today, I'm launching a crowdsourced initiative to track all these manual deployment tasks required with change sets.
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 of manual tasks required with change set would have the following benefits:
- Identify the best deployment tool to do the job.
- Measure projects risks associated with manual deployment tasks.
- Name blockers and research workarounds.
- Become a to-do-list for the product team.
Please support the initiative:
- Check the current state of our Spreadsheet on Quip.
- Join the conversation in the Success Community Group.
- Tweet us Meighan, Nitin or myself.
- Tweet your manual deployment tasks to #sfdcManualDeployTasks, we're listening!
As far as the UI is concerned, 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
But I suggest that you also check-out Johan Yu's posts on the topic for more information:
I'd love to see Salesforce improving the change sets UI as soon as possible but I guess that Salesforce DX is going to swallow all the specialised resources for a little while...
- 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.