Copado’s recent report, “The State of Salesforce DevOps Report,” provides an in-depth look at how DevOps is being implemented in large and complex Salesforce environments. With thousands of data points “collected from over 300 global Salesforce customers using DevOps,” this report includes lots of helpful information about how to accelerate the Salesforce release process with DevOps methods.
Below, we take a look at some of the key findings of the Copado report and what they mean for your organization, with a particular focus on findings related to test automation’s role in a modern Salesforce development and delivery environment.
Why implement DevOps for Salesforce?
If your enterprise is undergoing digital transformation, it’s likely that Salesforce plays a significant role. Many of the world’s leading companies spend millions of dollars on Salesforce as the single source of truth for customer data, and for good reason.
With a Customer 360 platform that spans multiple cloud solutions, a curated AppExchange with thousands of third-party apps and extensions, and APIs offering limitless customization potential, Salesforce both streamlines day-to-day customer-facing operations and anticipate future trends with data that helps companies better understand their customers and the marketplace as a whole.
However, this doesn’t just happen automatically. Nobody purchases Salesforce and then magically has all of their critical business objectives met. There’s no tool (yet, that is – I’m looking at you, future AI that will solve all of our problems) that can deliver such a monumental and unrealistic outcome. Let’s face it: Salesforce is awesome, and it can help you overcome some big challenges, but it takes the proper implementation. For most enterprises, the differentiating question is not “Am I using Salesforce?” but “How am I using Salesforce?”
This is where DevOps comes in.
According to the Copado report, “in order to maximize your Salesforce investment, teams must align it with a DevOps strategy that will unify the entire team, optimize the delivery pipeline, and establish the highest levels of security and governance.” The driver behind DevOps for Salesforce? Speed. According to Copado, “the study confirms that innovation speed is the #1 reason companies adopt DevOps.” But companies don’t want to move fast simply for the sake of winning a race.
They want to move fast because speed translates directly into money. According to the report, “The highest performing companies are building a DevOps strategy…with over 17% reporting an ROI of over $5 million.” That’s no menial number. With the potential ROI already in the millions, and the discipline of DevOps still maturing, the potential return could end up being in the tens of millions if your teams get it right.
What it takes: Speed + quality
The report examined what the top performers in Salesforce DevOps do differently and found that they tended to score higher in both release velocity and quality. According to the report, “High innovation delivery performance has been shown to drive organizational performance.”
In other words, your ability to deliver rapid innovation depends on the quality and speed with which you deploy. And fast, high-quality releases that adapt quickly to business users’ needs can kick your entire organization’s performance into overdrive.
Putting speed and quality into action: Automation, tooling, and accessibility
To ensure quality at speed, you have to have a testing strategy that is both adapted to modern DevOps processes and advanced enough to cover custom and standard Salesforce updates – as well as third-party app and data integrations. That’s a tall order, but you can significantly streamline the process with testing that’s automated within a single platform.
The next question, then, centers around tooling. What tools do Salesforce teams and organizations need to implement speed and quality for Salesforce releases? According to Copado, the highest performers are choosing commercial tools over open-source tools. As organizations and their Salesforce usage (and complexity) scale, they’re more likely to turn to a commercial tool that’s designed for testing Salesforce in a DevOps environment.
“80% of larger teams used Salesforce-specific commercial tools to aid in their development lifecycle. While smaller teams relied on generic DevOps tools or tools built in-house, none of the larger teams of Elite performers did so.”
In order to drive organizational performance, teams need to “adopt a commercial DevOps platform designed for the Salesforce platform.” Salesforce is unique in the world of enterprise applications, so the tooling you choose must be built in a way that can adapt and ensure quality across the Salesforce environment.
Copado also mentions the importance of involving the business in decisions related to Salesforce application management. That’s because “Salesforce is perhaps the technology platform most commonly shared between the business and IT.”
This is an area that many organizations forget about when defining and implementing strategies around quality. The highly technical processes and scripts developed the Salesforce release team can alienate the business user. If developers struggle to maintain scripts across releases (and they do), then how can we expect non-technical business users to be able to contribute?
The main takeaway here? If the business is going to be so heavily involved in the ownership of Salesforce (or any other enterprise app for that matter), they must also take ownership of the quality. This means that when teams make decisions about how to test Salesforce, they must factor in accessibility and scalability across a variety of stakeholders with varying technical skill levels.
The report makes the benefits of f DevOps in a Salesforce environment clear, and the findings make a strong case for the importance of a Salesforce-specific testing strategy. At Tricentis, we talk about a “Quality 360” approach to Salesforce testing. If you’re interested, you can learn more about Tricentis’ “lightning fast” Salesforce testing solutions here.