Is there a better way to do Salesforce change sets?
A big advantage of developing on the Salesforce platform is the sandbox paradigm. Sandboxes are a relatively easy way to create test and development environments - you can just log into a GUI, select which type of environment you want to create and Salesforce takes it from there. Relative to previous development stacks where you had to manage your own test environments this is a huge win.
And adoption has been great. Anecdotally from the past few Salesforce developer conferences we have been at, it seems like everyone has fully embraced the sandbox model of deployment. Even small shops that don’t have elaborate Salesforce CI pipelines are typically at least making changes in a sandbox first and the porting it over to production.
A key component of the Salesforce sandbox paradigm are change sets. Change sets are what allow you to migrate metadata changes from one developer environment to another or from a developer environment to staging or into production. If you don’t want to use Ant scripts and the Force.com migration tool change sets are a great, simple option as they come with a nice user interface and minimal maintenance.
By this point, most Salesforce developers and admins have probably encountered and used change sets. And accordingly, most Salesforce developers and admins have probably at some point or another thrown up their hands in frustration with change sets.
First off, change set management is highly manual. You have to remember what has changed and all dependencies between them. We have talked to large organizations who have as many as five spreadsheets flying around over email and Slack just to manage this stuff. Then when it comes time to deploy, they take a whole day (or sometimes a week!) where development is frozen and they make sense of what has changed and what all the dependencies are.
All this manual labor isn’t just painful: it’s a recipe for disaster. Any manual process is likely to cause issues because it leaves open the possibility of human error.
The biggest problem with change sets though is that they are “clobbery”. A change set simply performs a fresh rewrite of your Salesforce metadata. There is no concept of history or differential changes. This means that a change set can easily wipe out months of work from another developer.
Also, when bugs do get through (as they do more often than not when there is a manual process involved) there is no way to rollback to a previous state.
There are key benefits to change sets that we would never want to lose, namely:
But there are also a few things that can be improved:
Fortunately, Git makes it possible to get all of these improvements. As a source control tool, Git makes merging and branching easy and allows for rollback to previous states relatively quickly.
To make Git even easier and more change set-esque, Blue Canvas has developed a user interface that makes a Git-based deploy as simple as pushing a few buttons. Diffs are automatically highlighted but you get a GUI for selecting which files to include in your deployment. You no longer have to go hunting or remember what you changed or worry about unexpected dependencies.
Promoting work from one sandbox to another or to staging or production can be done in seconds and continuously throughout the day. This eliminates the need for large, month-long error prone releases and instead lets you be agile in your Salesforce development.
Ultimately, deploying with Git instead of change sets saves you money and time by incorporating more automation into your Salesforce release management process and reducing the number of bugs and hours spent debugging them. You can try it here in just four clicks!
A quick look at the best practices for Salesforce development that have emerged in the past 3 years and in the era of Salesforce DX.
What is the Salesforce Lightning Design System? Should I use it?