Why Salesforce Developers Need Source Control

Why Salesforce Developers Need Source Control

Last Updated on June 1, 2022 by Rakesh Gupta

Why every admin, developer, and architect should use source control.

This is a guest post by Alex Brausewetter, founder of Blue Canvas. Blue Canvas builds tools for Salesforce developers and admins looking to implement source control and CI.

Nearly all modern software development teams use version control today. Unfortunately, the Salesforce platform has made it extremely difficult to set up a proper version control system and accordingly too few Salesforce developers, admins and architects are actually using any kind of version control.

Why do you need version control?

Version control is essential in any collaborative software development environment. It allows developers to work together in an efficient and safe way.

Managing a multi-developer code base can be a challenge, especially with Salesforce. One of the biggest issues Salesforce developers have today is code clobbering. Code clobbering happens when one developer overwrites the work of another. We’ve talked to over a hundred Salesforce developers in the past few months and have heard horror stories where one developer wipes out the work of other developers on their team with no way of getting the work back.

Version control also allows you to rollback to previous versions of your application. Have you ever introduced a bug that caused havoc with your end-users? Source control allows you to quickly identify what changed in what version and quickly patch back to a stable version as needed.

Version control also allows you to do code reviews. Tools like GitHub, Bitbucket and GitLab all make it easy to have developers review each other’s changes before deploying. This increases code quality and improves the skills of your team.

Source control is all about providing more visibility into what’s going on with your code. A good source control system will let you see who has changed what and when. It will give you the ability to review the entire history of an Apex Class or Workflow Rule. How has it evolved over time? Who has been involved?


Git has emerged as a leading tool for setting up Source Control. This is because Git is fast, distributed and designed for collaboration. With Git, you can keep a running history of every change that happens in your code base and has a clear picture of who made the change and when.

Git’s branching workflow makes it a favorite among software developers in all industries. Branching allows developers to handle pesky merge conflicts with grace, preventing code clobbering from occurring. Developers can work on their own code without disrupting others.

Tools like GitHub, Bitbucket and GitLab have all made a collaboration with Git a much easier proposition than it used to be. These hosted services give you great user interfaces for leveraging the power of Git and take care of the mundane and difficult maintenance tasks associated with running your own Git server.

However, it can be difficult to use Git with Salesforce because of the unique way that Salesforce works.

Why Source Control Can Be Especially Hard for Salesforce Developers

Part of why Salesforce became the dominant platform that is today is the “clicks, not code” philosophy. This has empowered millions of people around the world to develop great applications without having to learn to code.

But this strength turns out to be a weakness from a source control and collaborative coding perspective. Because declarative changes are a part of the Salesforce paradigm, one cannot simply set up a GitHub repo with Salesforce. Furthermore, there are many stakeholders in Salesforce who may not necessarily be familiar with Git and don’t have time to learn. Not only do you have Salesforce developers, admins, and architects – you also have product managers, sales ops managers, business analysts and a host of other people who may make changes on your Salesforce Orgs.

It is important that every change on your Salesforce Org be tracked in version control. If someone logs in and makes a quick change in production without committing it to the source, the hard work you spent setting up your source control system is wasted.

Most development environments are code based for deployments so there is a clear concept of “source of truth”. Historically, the source of truth for Salesforce has been the Org itself. Salesforce DX is expected to change this, however, the details remain unclear.

So how can Salesforce professionals get the benefit of source control on their native platform?

Easy Source Control with Blue Canvas

Blue Canvas makes setting up version control with Git easy. With Blue Canvas declarative changes are automatically committed to your Git history. No one on the team needs to change their workflow to get the benefits of source control. Power users are able to use the full capabilities of Git and can even deploy their code by pushing to their Blue Canvas branches. To learn more check out Blue Canvas

Formative Assessment:

I want to hear from you!

What is one thing you learned from this post? How do you envision applying this new knowledge in the real world? Feel free to share in the comments below.

Have feedback, suggestions for posts, or need more information about Salesforce online training offered by me? Say hello, and leave a message!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.