Right, we need to let off some steam. After some time working with deploying using Ant, we needed to switch back to working with changesets and it has re-surfaced some long-held distaste for them. Between page refreshes, it has reminded me about several pain points and just how lacking changesets are.
Now we all know that DX is coming and there are other slicker way of deploying, so there are alternatives, but it’s difficult to understand why Salesforce has allowed changesets to work like this – clunky, neglected and unloved for years. With some simple additions it could be a whole nicer experience.
The Problems:
- The process of adding and removing components is painfully slow…. yawn.
- There is no quick way to find components to add… need to go through a-z pages / and then paginated pages.
- When selecting fields, only the label is provided. Need api name to make the right call.
- Large sets are unwieldy… need to use pagination to go through the set.
- Items can only be deleted one at a time (once you have found it in the paginated list) and then the changeset is refreshed and you need to restart navigation.
- Simply reviewing a large changeset is hard to do.
- Changesets can’t be re-used on other orgs, need to be regenerated. More fun.
- Validating can only be done once a changeset is closed and pushed up an environment. It doesn’t always appear in good time on the higher environment.
Some Suggested Improvements:
- Simply redo the navigation and selection actions to be quicker and slicker.
- Allow users to change page pagination size
- Allow a free search text box to find components easier.
- Present recently modified components in a quick select section.
- Show more columns on UI for selection / display of components… to aid review, ensure correct component selected. I’m thinking api name, last modified date, last modified by.. Actually, allow users to select the columns they want to see or allow then to create and select different views.
- Allow a changeset to be exported to Excel. (For review purposes or for backup or import on another org)
- Allow a changeset to be created by importing appropriately formatted excel file. (Also allow appending to existing)
- Allow a changeset to be validated against another org with having to upload or swap orgs. (user provides credentials.) No need to log into another org, wait for package to arrive and then having to clone and repeat process to fix any issues.
There doesn’t appear to be an accessible api for changesets (let us know if this is not true), as there would definitely be some scope to put some custom coding together to address some of these issues.
I have dabbled in package.xml generation and automation with Ant and jenkins and deployment can definitely be streamlined and improved. There are things you can do with the metadata api. We need to see what DX means for changeset in the future.
With the whole deployment space changing it would be nice to see Salesforce investing in some tweaks to good-old Changesets to keep us all happy (or at least sane).
