With all the benefits of version control compared to in-org development, one might expect the majority of Salesforce development teams to have adopted this approach. But the numbers are surprisingly low (although this is changing with the advent of Salesforce DX).

There are four main reasons for this.

Salesforce has a unique development process. With the more traditional platforms, the code is the specification of an application, and the application is built straight from that blueprint. When changes have been made, developers take the updated blueprint, compile the application from it, and deploy it. 

In contrast, with Salesforce, the application is a living, changing thing in its own right. "Clicks not code" means the application can exist entirely without a user-facing source code (metadata) representation. Rather than compiling the application from source, the source is generated from the current state of the application. An updated version of the application isn't created and deployed. Instead, it's modified in-place, either directly or through an API.

Because of this ability to modify the Salesforce org in-place, there hasn’t been the same urgency for tools to handle Salesforce source code. Consequently, the first-party tools for extracting metadata and deploying changes have traditionally been very limited, and this has hindered the wider adoption of version control. 

In the past few years, more advanced deployment tools have been created to fill this gap. These third-party tools enable Salesforce developers to enjoy the same level of metadata migration and management that is common on other platforms, while solving the nuances of working on Salesforce. 

With the advent of Salesforce DX, Salesforce has begun to push teams to adopt version control and is starting to modernize its underlying tooling. As a result, adoption is on the increase.

Many teams consider version control a solution that’s only appropriate for large enterprises, and not something a small development team can take advantage of. With a little planning, version control can bring a range of benefits to teams of all sizes.

Due to the relatively small number of Salesforce teams using version control, there is often a lack of understanding about what a good process should look like. The most common pitfall is over-engineering a process, which often ends up becoming more of a hindrance than a help. Teams bogged down in an overly complex process often revert to their old ways of working.

For admins or developers who aren’t familiar with version control or command-line tooling, there has traditionally been a lot to take in. Learning how to use the command line and edit code by hand — so that teams can commit changes to version control — is a hard sell when they already know how to make a change through the Salesforce UI. 

Luckily, release management with version control doesn’t have to be difficult. With a good release model and a modern deployment tool, it's easy for teams to create a simple yet effective process that works for developers, admins, and managers of all experience levels.