How to Automate Your Salesforce Releases

By David Runciman

How do Salesforce teams manage their releases? Gearset’s latest report, The State of Salesforce DevOps 2022, gives the full picture.

Based on survey responses from more than 1,000 Salesforce admins, developers, and IT leaders, the report shows which DevOps tools teams have adopted, and the impact this has had on their performance, with additional analysis of key trends in the Salesforce ecosystem.

DevOps Adoption Continues at Pace

Source control is fast becoming the norm for development on the Salesforce platform, as it is for software development more widely. Two in three Salesforce teams already use Git and a further 23% are looking to introduce source control this year. If that’s you and your team, you might find one of these guides useful:

Once teams have adopted source control, the next step is to automate parts of their release process. For the first time, the majority of Salesforce teams have picked up tools for continuous integration and continuous delivery (CI/CD), and either have or are trying to establish an automated release pipeline.

DevOps Adoption vs. DevOps Maturity

Having the right tools for DevOps isn’t the same as having a mature approach to DevOps. For instance, many Salesforce teams using Git don’t yet treat their repository as the single source of truth. DevOps maturity takes time, and involves cultural change as well as picking up new tools and processes.

Salesforce teams are striving for DevOps maturity, and so the Salesforce ecosystem is in transition. The momentum towards DevOps is unstoppable, but only a few teams have reached true elite DevOps performance: releasing at least once per day, preventing most bugs and errors from reaching production, and being able to restore from data or metadata loss within a few days. Far more teams are still working on weekly or biweekly sprints and weighing up how DevOps might help them accelerate their delivery.

Automation: the Key Step in 2022 for Most Teams

DevOps maturity depends on automation. Manually promoting changes along a release pipeline, testing work, monitoring production, and backing up an org, makes it impossible to move at pace safely.

But all of these things can be automated, which is why a huge number of teams are looking to implement CI/CD and automate unit testing, org monitoring and backups.

Continuous Integration and Continuous Deployment/Delivery

CI/CD is an essential ingredient for a mature DevOps process, with automated validations and deployments removing huge amounts of manual effort and making it possible to construct more robust release pipelines. But many Salesforce teams are feeling the pain as they try to implement CI/CD. A staggering 80% say their CI jobs regularly need manual intervention, which obviously undermines the value of automation.

In some cases, teams may be switching on CI/CD too soon. A process can only be automated once it’s reliable and repeatable. So if your deployments don’t consistently succeed at the moment, then that needs to be addressed before attempting automation.

CI/CD also involves a cultural shift. Shipping incremental improvements more frequently is the way to go, because small release packages are less likely to contain something that causes deployment failure. Difficulties with automation may be putting teams off upping their release cadence, but that’s the very change that will help to reduce the likelihood of issues such as merge conflicts.

It’s important to emphasize that success with CI/CD is absolutely achievable. Teams that embrace DevOps as a new way of working and use intelligent tooling built specifically for Salesforce, achieve DevOps maturity. They release multiple times a day and experience all the benefits of DevOps: increased productivity, better collaboration, improved release quality, reduced costs, and more.

Automated Unit Testing Throughout the Release Cycle

It’s a common misconception that DevOps is all about speed. It’s true that DevOps does accelerate delivery, getting value to the business sooner and driving increased ROI from Salesforce. But DevOps is also about release quality.

Continuously deploying changes along a release pipeline means that work can be tested frequently, with most bugs or errors being caught long before making it to Production. Automated unit tests should also be run for Production code, to make sure your Apex continues to behave as expected and that code coverage remains above the 75% threshold enforced by Salesforce.

Salesforce teams admit to releasing bugs and errors surprisingly often, with 19% doing so in more than half of their releases. These change failure rates can be significantly reduced thanks to DevOps. Automation makes it possible for teams to add environments to their release pipeline, with automated testing and validation baked into the CI/CD process, plus gating for quality control.

Monitoring and Backups to Safeguard Investment in Salesforce

Another overlooked but critical aspect of DevOps is the security and resilience it brings. Knowing your Salesforce data and metadata are recoverable gives peace of mind and makes it possible to innovate without the crippling fear of doing irreparable damage or losing control of Production.

Monitoring is often cited as a key DevOps process, but Salesforce is a unique platform with unique monitoring requirements. There isn’t the need for things like infrastructure monitoring – Salesforce itself handles that. There is, however, a need to monitor for unexpected or unauthorized changes to data and metadata, since the Salesforce platform makes it so easy to make configuration changes directly in Production. This kind of monitoring can’t be done manually; it requires automation.

Alongside monitoring, every Salesforce team needs an automated backup solution. Being able to restore data and metadata is vital, since more than 50% of companies using Salesforce suffered data and metadata loss incidents last year. Many companies still haven’t protected their investment in Salesforce, although third-party solutions are the most popular approach among those that have.

The question of ownership often crops up when we’re talking about backups. Teams who are responsible for releasing on Salesforce are ultimately responsible for the backups too, even though they might not realize it. Indeed, backups really belong with DevOps.

Final Thoughts

Gearset’s State of Salesforce DevOps report is freely available here. For more data-driven insights and analysis that will help your team understand and implement DevOps, download your copy!

The Author

David Runciman

Technical Author at Gearset, the leading DevOps solution for Salesforce.

Leave a Reply