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:

  1. They only support a subset of Salesforce configuration components.
  2. The user interface sucks.
  3. They look like a simple tool but come with many gotchas.
  4. They don't manage dependencies as well as Packages do.
  5. They have a complex relationship with Profiles and Permission Sets.
  6. They don't carry over deletions nor rename operations.
  7. They can't be reused in the destination org (by a different team).
  8. They can't be merged.

In this post, I'm focusing on the first two issues. The other ones can be considered to be advanced use cases for Ant (try my fabPack) or now Salesforce DX.

Unsupported Components

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:

  1. Identify the best deployment tool to do the job.
  2. Measure projects risks associated with manual deployment tasks.
  3. Name blockers and research workarounds.
  4. Become a to-do-list for the product team.

Please support the initiative:

Crowdsourced Quip Spreadsheet

User Interface

As far as the UI is concerned, there's way too much work to expect a quick fix.

The short term workaround is to use third parts Chrome extensions. Boostr from Matt Simonis is currently my favourite one.

Boostr

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...

Related Resources

I hope you enjoyed this post. Don't hesitate to ping me on Twitter if you have any comment or question. Bye for now!

Fab 🐸