What Makes CI/CD for Salesforce Different?

Globally, more than 150,000 businesses use Salesforce. And since the CRM is also a development platform, there are more than 1.5 million Salesforce developers building apps, automated business processes, and more.

Many IT departments assume that Salesforce development and releases can be approached in much the same way as other platforms and expect to be able to apply DevOps best practices. But all too often, bringing a continuous integration and continuous delivery (CI/CD) playbook from other platforms to Salesforce ends in failure.

CI/CD and DevOps Adoption on Salesforce

The practices that underpin DevOps, such as CI/CD, are newer to the Salesforce platform. In recent years there’s been a surge of interest in DevOps, with thousands of businesses wanting to improve their Salesforce release process and performance. According to the latest figures, 44% have adopted CI/CD for Salesforce, but another 39% want to adopt it this year.

In this article, we’ll look at the three main reasons why CI/CD for Salesforce needs to be tackled differently if those teams are to be successful.

The Salesforce Platform Presents a Unique Deployment Challenge

Salesforce configuration and customizations are deployed as files of metadata, with many unique metadata types that each have their own quirks. Releasing to Salesforce with native tooling is a surprisingly painful experience, with high rates of deployment failure due to missing dependencies or any number of other issues.

In a Salesforce release pipeline, a typical job that teams want to automate is deploying the latest metadata from their version control system (VCS) to a Salesforce environment for validation and testing. Teams attempting to automate this kind of job with tools such as Jenkins often stumble on the fundamental challenge: deploying metadata to Salesforce environments. As a result, 80% of teams report their automation jobs are frequently stalled, with errors that require manual intervention. Validating changes in Salesforce is no mean feat without a process that can reliably get changes into a Salesforce org.

Salesforce also frequently releases new and updated metadata types and periodically upgrades Salesforce environments. These changes mean any self-built CI/CD setup needs constant attention and maintenance. Teams can end up dedicating developers to managing scripts, automation tools, servers, and authentication methods.

There are still more technical challenges, too. While Salesforce is primarily a CRM, businesses increasingly use it to streamline and automate a much wider range of business processes. Salesforce’s ‘clouds,’ such as Revenue Cloud and Experience Cloud, provide functionality out of the box that developers can extend and customize for different departments or projects. Some of these clouds are former third-party products that Salesforce has acquired, and under the hood, the configuration is represented quite differently. Integrating different work streams from the development work on these clouds and creating one unified release process is a considerable challenge.

All in all, Salesforce is a different enough kind of platform to make a different approach to CI/CD necessary. This explains why there’s a booming market for Salesforce-specific DevOps solutions.

Salesforce Teams Are Often Siloed According to Technical Experience

A large proportion of the people building on Salesforce aren’t traditional developers writing code but no-code or low-code developers. Salesforce has invested heavily in declarative tools that enable administrators and configurators to build increasingly sophisticated features with “clicks, not code.” With Flow Builder, teams can create advanced business logic; with Experience Builder, they can create sites and portals.

As a result, most businesses have no-code teams creating customizations, as well as teams doing more traditional development work for Salesforce. It’s common for these teams to exist in silos and struggle to collaborate with each other. In particular, no-code teams are often nervous about getting involved in releases or doing anything that sounds like ‘pro-code’ territory. On the other hand, developers may accidentally overwrite declaratively produced work with their deployments.

All this adds a significant challenge to building a CI/CD process for Salesforce. Achieving the cultural ambition of DevOps — removing silos and streamlining collaboration — has the added dimension that Salesforce teams’ technical experience varies widely.

Getting developers and configurators to collaborate on releases significantly improves overall DevOps performance. The State of Salesforce DevOps 2023 report found that teams who rate their collaboration highly also perform the best against DORA metrics.

Implementing the right Salesforce DevOps platform is key to success. Most CI/CD setups are geared toward traditional developers, but for Salesforce DevOps, it really helps no-code developers to have a friendly UI for deployments and other DevOps processes, including testing, monitoring, and backups. 

At the same time, coders don’t want to use tools that hide away the inner workings of the release process or replace tools that are already working. For example, there’s no need to rip out a Git hosting provider that developers are happy with, so it’s also important that DevOps solutions integrate tightly with teams’ existing tech stacks.

Expectations From the Wider Business Need Managing

In addition to the technical challenges of CI/CD for Salesforce and the particular makeup of Salesforce teams, it’s also worth considering how the wider business views the platform and the implications of that perception for release management.

Put simply: it can’t be assumed that businesses aspire to see frequent releases to Salesforce. This is particularly true at larger enterprises or in industries where risk management and compliance are a higher priority than speed and agility.

Salesforce orgs hold a lot of customer data, so any changes to Salesforce are likely to be scrutinized and audited carefully. Large- or small-scale data loss, accidentally triggering business logic such as automated emails to customers, or granting the wrong profiles access to personally identifiable information (PII): all of these and other potential risks make the business hit the brakes on releases.

Given this context, it’s surprising that the adoption of backup solutions for Salesforce has only risen above 50% in the last few years. As well as being a no-brainer for protecting customer data and the investment in platform configurations, proper backups create the much-needed confidence for embracing shorter release cycles.

It’s also a common misconception that CI/CD and agile development will inevitably increase risk. Placing an emphasis on testing and release quality can help address concerns about DevOps adoption for Salesforce. 

A release branch strategy can help teams steer their way to a compromise, with changes being continuously integrated but only released at the end of each sprint. But dialogue with the business about the merits of release automation is vital. Just as culture is the secret to success in DevOps, so too is aligning with the wider organization.

How To Implement CI/CD for Salesforce Successfully

There’s no one CI/CD setup that suits every Salesforce team. But there are general principles that apply in most cases and learnings from the thousands of teams that have managed to construct a well-oiled CI/CD process. You can find some key findings from the recent ebook CI/CD for Salesforce in this article.

The key takeaway is that CI/CD for Salesforce is absolutely achievable. Don’t be put off if you’ve tried and failed with automation tools that have worked for other platforms. And think twice before assuming that a self-built pipeline will be easy to set up and maintain. Salesforce is different, but it still needs DevOps.