Guarantee ROI with Salesforce DevOps automation

David Runciman on

Share with


Most teams adopting Gearset first notice the dramatic reduction in deployment times compared to using change sets. These time-savings translate into real cost-savings. The bottom line of your IT budget is healthier because devs and admins are freed up to work on building features that add value, rather than toiling away unnecessarily on manual, error-prone deployments. But savings on deployment times are just the beginning of a substantial return on investment in DevOps tooling.

Illustration - climbing cogs to reach dollars

The automation you need for Salesforce DevOps

More and more teams are maturing their DevOps processes for Salesforce and blazing a trail to show how it's done. The team at Healthcare giant McKesson, for example, have an automated deployment pipeline that saves time, improves their work, and just makes life easier. So what kinds of tools are involved when introducing automation to your release process? There are four key areas:

Continuous integration

Continuous integration allows you to have a release pipeline made up of several environments, without requiring additional manual work to promote release packages along the pipeline.

CI jobs in Gearset essentially automate your deployments or validations. You can configure the metadata filter so only certain types are deployed, and you can specify which tests to run on each deployment package. Any work that passes the tests and can be deployed successfully is automatically promoted, saving you the effort of a manual deployment. CI jobs also function as a gate - if a run fails, you know there's something in your package that needs fixing.

Continuous integration jobs in Gearset
Automated unit testing

Testing is an essential part of development and releases, making sure that new work is high quality and that releasing it won't break existing configuration and code in production. Automated unit testing is especially important. Unit tests check that your Apex classes are executing correctly, so testing new code before releasing it is obviously valuable. But you also need to test the code in production continually for two main reasons:

  1. Later changes can cause Apex classes in your org to begin failing. Automated unit testing makes sure these tests don't fail silently.
  2. Salesforce won't let you deploy to an org with under 75% code coverage. Automated unit testing in Gearset tracks your code coverage.
Change monitoring

Monitoring means different things to different people in Salesforce DevOps, which can cause confusion for teams working out what tools they need. In the wider world of DevOps, monitoring means keeping an eye on applications and infrastructure. For Salesforce teams, there's no need to monitor infrastructure, but there is a need to monitor the metadata in production.

Setting up automated change monitoring guarantees you'll know about any unexpected changes in production, no matter how they got there. You can then respond appropriately, either removing unauthorized and unnecessary changes, or deploying them back to your upstream environments so everything stays in sync. Without change monitoring, you're blind to any changes in production that might clash with subsequent releases or just be overwritten.

Backups of data and metadata

Ultimately, you need automated backups in place to secure the data and metadata in production, protecting not just business records but also all of the customizations your team has delivered. Backing up your org daily or even more frequently minimizes the amount of work that can be lost.

Analyzing our backup history in Gearset

Evaluating the automation in your Salesforce DevOps process

Savings on deployment times, as welcome as they may be, will ultimately be dwarfed by the return on investment in DevOps for Salesforce. To understand why that's the case, and to guide your thinking in terms of an actual calculation of projected value that you can present, it's useful to consider the standard metrics for DevOps performance and the business value they each represent. At every stage, automation will drive your DevOps improvements, which in turn yield a return on investment.

Lead times

A source-driven, CI/CD process makes it possible to reduce your lead times, which in turn increases the return on your business's Salesforce investment. The whole purpose of customizing Salesforce is to streamline processes, make teams right across the business more effective, and ultimately to add value. However much value your work is worth to the business, you can increase that value by getting the work into your end users' hands sooner, giving them more time to make the most of what you've built.

The potential for ROI in this area depends on your current performance. Many teams finish work long before it's eventually released alongside a bunch of other features and improvements. Shipping this work as soon as it's complete cuts out the waste of completed work that's not being used to improve business performance. If, on average, you can deliver work in half the time, you've doubled the impact of your team.

Release frequency

Shorter lead times go hand in hand with releasing more frequently, both of which are facilitated by automating your release pipeline. Teams considered elite DevOps performers release multiple times a day, rather than biweekly or even monthly. High release frequency is essential for reducing lead times.

The business value of increased release frequency is also that it leads to more relevant features and improvements. Rather than releasing an entire feature at the end of a long project, teams practicing DevOps release incrementally. This allows them to gather feedback from end users as they go, and adjust their work accordingly. Not only do end users see slices of work delivered sooner, they have more input into the shape of the customizations they need.

By avoiding the situation where a feature needs to be reworked, just because it doesn't quite match your end users' requirements, your team certainly saves time. But it's notoriously difficult to quantify the precise value of qualitative improvements to the features you build.

Change failure rates

Automated unit testing and change monitoring both help to reduce change failure rates, another key DevOps metric that measures what proportion of releases contains a bug or error. Testing and monitoring make sure your team can catch errors early, either before they're released or soon after a breaking change is deployed. Monitoring also alerts you to hotfixes in production that you want to keep, and saves you from overwriting them with the next release, then needing to recreate the hotfix.

Automated testing and monitoring save valuable developer time. Bugs and errors always cost time and effort, whether a release needs debugging straight away or not. Gearset's State of Salesforce DevOps 2021 report found that some teams have a change failure rate above 50%, while a third of teams find bugs in 10-25% of their releases. Respondents also said that these bugs typically take days to fix, each costing thousands of dollars in developer time. How long did your last bug take to fix?

Change failure rate stats
Recovery times

Short recovery times are your insurance policy against any damage to your org, whether it's caused by human error, a release or integration gone badly wrong, or any other incident. Automated backups with a powerful restore tool are necessary to ensure you can recover from any data loss in as little time as possible.

The ROI of a backup solution is typically calculated by valuing what could be lost. How much is your Salesforce org worth, with all the data and customizations it contains? What about the reputational damage that comes with losing data? Putting a figure on this can seem arbitrary, and some calculations of DevOps ROI produce an astronomical number for the value of disaster recovery. By all means do that if it makes sense in your context; or perhaps just conclude that backups are invaluable!

How to calculate Salesforce DevOps ROI

It isn't easy to calculate the precise ROI for DevOps because it's a way of working as much as a set of tools. But where cutting deployment times alone quickly repays the investment in Gearset, it's clear that building an automated DevOps process multiplies that return. For more help in considering your investment in DevOps, book a consultation with one of our experts.

Ready to get started with Gearset?

Start free trial