Deploy and Update Source Control in One Step

Jan 16, 2018

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.

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.

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.

Signup to get blog posts about Salesforce development, source control and Continuous Integration every week.