Best Practices

The Art of Salesforce Release Management

Exploring better ways to do Salesforce release management

Last Update:
June 12, 2023
June 20, 2017

This article covers how to navigate the challenge of releasing software updates quickly while ensuring the product remains reliable and bug-free. We'll dive into different strategies for Salesforce release management, examining the balance between deployment speed and quality, and discussing how regular deployments of smaller updates can enhance your business operations.

Here are our 5 Key Takeaways:

  • Balancing fast deployment and high-quality software is crucial to successful release management.
  • Coding in production may seem fast but compromises quality significantly.
  • While convenient, change sets can be slow and error-prone due to their manual nature.
  • Ant scripts offer moderate speed and quality, enabling automation but still requiring maintenance.
  • A Git-based approach provides high speed and quality by offering automated tracking, differential deployments, and built-in version control.

Table of Contents

Software teams can easily empathize with taking extra precaution to limit downtime.

But Spolsky notes that there is also a cost associated with having too much inventory. Companies like Toyota have gone to great lengths to ensure that they have just the right amount of inventory and no more. Having too much inventory is problematic because it ties up resources in an unproductive way. If you have $100,000 in inventory, that’s $100,000 not being spent on something useful. (Interestingly, many companies actually use Salesforce and the to manage their inventory!)

As Spolsky puts it:

The “cost” of code inventory is huge. It might add up to six or twelve months of work that is stuck in the assembly line and not yet in customers’ hands. This could be the difference between having a cutting-edge product (iPhone) or constantly playing catchup (Windows Phone).

His suggestion?

Don’t let completed features pile up in ways that don’t make you money. Work on your deployment process so that you can get customers features in months rather than years. If you’re already shipping monthly, figure out how to ship weekly. Keep pushing the bar on more and more frequent deployment of smaller and smaller changes.



Getting inventory out the door quickly is a competitive advantage for teams. Features that pile up and remain undeployed are expensive just as too much inventory is expensive. However, there is a competing interest that every release manager is well aware of: quality. You want to avoid having too much inventory piling up, but you also want to assure that your product is high quality. You can’t simply sacrifice quality in the name of speed. Launching fast is a competitive advantage but bug ridden software is not. This is a visceral pain that most software teams feel acutely. Anyone who’s ever released a semi-major bug knows that you will hear from your users loud and clear if things aren’t working as expected.

Managing both of these interests is the art of release management. Any release manager has to deal with this. But it’s especially acute in the Salesforce ecosystem where there is a wide variety of stakeholders who can be involved in development and release management: admins, developers, architects, business analysts, product managers, etc.

So what are the options for a Salesforce release manager?


Quality: Very low Speed: Fast in the short term

At this point, we don’t really need to convince you why this is not a good idea, right?


Speed: Low Quality: Low

Change sets are the out of the box release management option from Salesforce. They allow you to migrate code and configuration changes from one Salesforce sandbox to the next using a graphical user interface provided by Salesforce.

Change sets are convenient because they come out of the box from Salesforce. You don’t have to set up anything custom and you don’t plan to do maintenance on custom scripts. You can be fairly confident that change sets will continue to work as new Salesforce release come out.

But unfortunately change sets score fairly low on both our speed and quality metrics.

Change sets are slow because they require a lot of manual hand holding. You have to manually keep track of everything that has changed in a given release. (We see a lot of teams using spreadsheets to do this.) This is time consuming and ineffective because it is so easy to forget to log all changes. Furthermore, there is a pretty complex dependency tree in any given Salesforce deployment. Change sets provide some functionality here but it’s not always fully accurate. So deployments do not always go through smoothly and can take several attempts. Finally, it’s slow because it requires so much clicking. There is not an automated way with change sets to simply say “Tell me everything that is different between my developer org and the UAT environment I want to deploy to.” Automating this alone would help speed things up significantly.

But change sets also suffer on the quality scorecard. Manual process are prone to human error key dependencies are often missed and the deployment causes unexpected issues. Furthermore, change sets provide no concept of versioning or source control. This makes rollback difficult. It also makes collaboration problematic. Without source control there is no way to ensure certain developers or admins are not overwriting the code of another.


Speed: Moderate Quality: Moderate

The migration tool, also colloquially known as, “ant scripts” is another option that many release managers turn to. The migration tool is based on Java/Ant and can be run from the command line. It allows Salesforce developers interact with the Salesforce metadata API to deploy changes. It’s a great tool.

The nice thing about Ant scripts is that they allow for far more automation than change sets. They even allow you to get closer to continuous integration for Salesforcebecause of this degree of automation.

The biggest challenge with Ant scripts is that they are still not as fast as possible because they are based on Java and highly reliant on querying the Salesforce APIs which are not always performant for large orgs. It’s also challenging to do differential deployments which only write the changes that are actually new.

The migration tool workflow tends to promote higher quality releases because it presumes that you use some kind of source control tool for version management. Ant scripts also automate more for you and remove the possibility of human error. However, they still require quite a bit maintenance as new API versions and releases come out. So you may find that the automation is less reliable than you might initially hope for.

The other big question for release managers is how to train your entire team to use your release workflow with the migration tool. What is the best way to ensure your entire team follows the process and does not deviate? For example if an admin goes rogue and makes a quick change directly in an org, this can break your release pipeline. So you have to think about this when accounting for quality.

Salesforce Release Management with Blue Canvas

Speed: High Quality: High

Okay we’re obviously biased, but hear us out. Blue Canvas is designed to optimize the speed and quality trade off for Salesforce release managers. Because Blue Canvas is based on Git at it’s core, there are a number of advantages. The first is speed. Git is written in C and is therefore very fast. Blue Canvas can also minimize the amount of times we need to go directly to the Salesforce APIs which speeds up your release process further. Finally, deployments with Git are incremental so we can deploy only the changes that are different in each given deployment. This is an improvement over Ant scripts which require you to reupload everything.

Blue Canvas also scores well on quality because it keeps things highly automated. Blue Canvas automatically tracks everything that changes on your org. You can quickly query and see what has changed or compare the differences between environments. You aren’t relying on training your team to use a new process. Also, because Blue Canvas is Git based, version control is automatically built into your release management pipeline. This gives you continuous backups and safe merge conflict resolution. If you ever need to rollback you can. And you don’t need to worry about about developers or admins overwriting each other’s work without recourse. Everything is backed up in Git automatically.

Get started now with Salesforce Continuous Integration

Our developer tooling helps you compare Salesforce orgs within seconds, can merge changes from multiple sandboxes into one, and backs up your Apex and metadata changes on a continuous basis!

More like this