With all the benefits of version control over 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.

Limitations of the first-party tooling

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, it's modified in-place either directly, or via 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’ support for extracting metadata and deploying changes have traditionally been very limited, and this has hindered 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 have begun to push teams to adopt version control and are starting to modernise their underlying tooling. As a result, adoption is on the increase.

Thinking version control is only for enterprises

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.

Not knowing what good looks like

Due to the relatively small numbers of Salesforce teams using version control, there is often alack of understanding of 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.

Technical barriers of command-line tools

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 teams can commit changes to version control is a hard sell when they know how to make a change via 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 which works for developers, admins and managers of all experience levels.

Did this answer your question?