Salesforce has become a popular development platform, but implementing source control can be challenging. Blue Canvas offers a solution.
With this article, learn about the importance of implementing source control in Salesforce development and the challenges that come with it. I also discovered how Blue Canvas solves these challenges by automatically committing changes in real time and linking deployments to source control.
Here are our 5 Key Takeaways:
1. Salesforce has become a full-fledged development platform, and source control is now universally seen as a key business priority.
2. Git and Salesforce have a fundamental challenge because Git is very accepting while Salesforce is not.
3. Blue Canvas solves this challenge by automatically committing changes in real time and linking deployments to source control.
4. Implementing source control can save medium-sized teams $250k-$750k per year in hidden costs and lost productivity.
5. Having a source of truth for Salesforce is the first step towards making the Salesforce experience better for end users and developers.
FREE TOOL
Profiles & Permissions Deployer
Easily compare and deploy Profiles, Permission Sets, and Field-Level Security (FLS) between any two Salesforce organizations.
Get Started
Made with love by the Blue Canvas team ❤️
Over the past decade, Salesforce has emerged as the premier tool for business application development. It wasn’t necessarily designed to be that way from the start - it just sort of happened as Salesforce responded to customer needs. Accordingly, software development best practices like source control have never been a major priority for teams. But as more and more applications were built for Salesforce and larger and larger teams got involved, it became clear that Salesforce had become a full-fledged development platform. Teams were rapidly switching over from .NET and other platforms because of Salesforce’s security, reliability, backwards compatibility and low-code development options.
In 2018, many teams are still working to implement source control, but it’s now universally seen as a key business priority. More and more Salesforce teams see the value of investing time and money into setting up a good source control process for Salesforce. A big part of that is Salesforce DX which insists that source control is now the “source of truth” for Salesforce.
However, there is a fundamental challenge that almost every Salesforce development shop faces when setting up source control.
Salesforce is Like an Exclusive Dreamforce Party One major problem with Git and Salesforce is that Git is very accepting, while Salesforce is not. Git will happily merge almost any push. Git checks for merge conflicts but is completely divorced from Salesforce deployments and dependencies. You can push a bunch of incorrect syntax and changes which are completely incompatible with Salesforce to Git without being warned. Git will happily accept your changes with open arms. It will be fast. It will feel good. You’re doing source control! What’s the problem with that? For better or for worse, Salesforce is a little more choosy. It’s like an exclusive Dreamforce Party: it can be a bit tricky to get in. You have to have the right syntax and that all dependencies are aligned.
If you’re not careful, code and configuration metadata that can’t be deployed to Salesforce may end up in Git. So very quickly your Git repo and your Salesforce orgs are out of sync and say completely different things. DX insists that source control be your source of truth , but what if the org says something different? Which is the actual source of truth? If you need to do a Salesforce audit , which do you follow? Probably the org, right? That is what your end-users are actually seeing and interacting with.
This problem compounds over time. The longer you are pushing to Git without proper Salesforce validation, the further divorced your Git repo is from your orgs. And the harder deployments get because your source control isn’t accurate. And this only makes it more likely to have your org and source control get out of sync. And this makes deploying harder. It’s a vicious cycle.
Blue Canvas solves this conundrum in two ways:
Real Time, Automated Commits for Salesforce First, we automatically commit everything on the org into Git in real time. This ensures that the repo is always reflecting the current state of the org - whether it’s a sandbox or production environment. Make a quick change in prod? It ends up in Git automatically. Sales ops person update an email template that is referenced in a class? It’s all connected to Git. Everything is committed in real time with the real username of the committer.
You can easily hook this up into external Git repos so at the very least your code base in Git is always in sync with your Salesforce metadata. We suggest our customers start with this at the very least because it helps resolve the source of truth problem in Salesforce with only 4 clicks of setup .
Linking Deployments to Source Control Automatically Second, Blue Canvas ties deployments to source control in a way no other tool does. With Blue Canvas, pushing to source control is an automatic step that is part of the deployment process. Blue Canvas has a concept called Deployment Requests . These are like Pull Requests in the Git paradigm. The deployment request is conceptually like a change set except it’s all automated and much easier to use.
When you create a Deployment request Blue Canvas automatically performs a test Git merge to ensure that there are not merge conflicts. If there are, we’ll notify you like so:
If there are merge conflicts (because some other team member has pushed changes to the org) you will be notified. Rather than just blindly overwriting the code. We have built an intelligent service that can actually determine the intent of your code. So if you make a declarative change we know the intent behind it. We know if it’s a real change or just an arbitrary reordering of the XML that Salesforce does from time to time.
Our second step is to run a Salesforce validation. This does all the syntax checking and dependency analysis. For example: are you deploying a class that references an object that isn’t in the target org? We’ll catch these things and let you know.
Our third and final step is to merge the code changes into Git and deploy to Salesforce at the same time. This simple automated step is crucial to solving the source of truth problem. It ensures that what you see in Git is accurately portraying what you see in the org. We won’t deploy if you can’t merge, and we won’t merge if you can’t deploy . This ensures that Git is just as exclusive as Salesforce. Which makes your entire development process much simpler and less error prone.
Why does this matter? Some of this can seem kind of arbitrary and superfluous. “Our Salesforce process is fine after all,” you may say. Well, it matters for several reasons. First of all, not implementing source control can costs you $250k-$750k per year in hidden costs and lost productivity if you are a medium sized team. Also, if you are interested in SOX compliance, you need to ensure that you have a real source of truth in place to be able to audit your code and configuration metadata.
Finally, Salesforce is a real development platform. You have hired either a team or consultants to build customizations to your mission critical business processes. It’s worth investing in making this experience smooth, safe and reliable. Having a source of truth for Salesforce is the first step towards making your Salesforce experience better for your end users and developers as it results in faster deployments, fewer bugs, and a more agile and iterative process.
