How Blue Canvas improves upon Git Flow and Salesforce DX to bring DevOps best practices to Salesforce teams.
Today, there are probably very few software development teams in your organization who are not effectively using source control in some fashion, and most are probably using Git in some form.
Well, all except one that is: your Salesforce development and admin team. Your Salesforce team may have a Git repository somewhere, odds are they are not getting the full benefits of source control. Which ultimately means that your Salesforce teams are not as protected as your other development teams from issues like bugs (and needing to roll them back), and they are not working as effectively as they could be.
This white paper explains why Git Flow with Jenkins (the traditional way software teams use Git) and Salesforce DX (Salesforce’s approach to solving their developer experience problem) do not work well for Salesforce teams. It also lays out how you can get the benefits of modern DevOps tooling and Git through tools like Blue Canvas.
Salesforce won the ignominy of being called the Worst Developer Platform in 2013 and 2015 (2nd worst in 2014). In 2016, the company announced “Salesforce DX” which stands for Developer Experience. The idea was to bring modern DevOps tooling to the Salesforce platform in order to modernize the way Salesforce teams did software development.
It struck all the right tones. It preached “source driven development” and encouraged teams to think of source control as the source of truth* rather than the Salesforce org itself.
It promised new types of orgs called Scratch Orgs which would be light weight environments that could be spun up quickly almost like virtual environments or virtual machines.
And it offered a new Salesforce CLI which was meant to be a modern interpretation of the Java based Ant Migration tool and the more sophisticated Salesforce developer teams have been using.
We are big fans of what the DX team is doing and what they are trying to change about Salesforce development. It’s a great effort and so many of the core principles make sense. In fact, at Blue Canvas we leverage Salesforce DX in a number of ways - especially the awesome new directory format!
However, after two years of working with Salesforce teams attempting to implement DX, we believe that while it is well intentioned, it misses the mark in some fundamental ways - just as the Git Flow and Jenkins approach has been difficult for teams to use.
The primary reason is that Salesforce DX is based on Git Flow which is the basic way that software teams use Git.
Most software teams use Git Flow to keep track of multiple branches in parallel and use Git via the command line to maintain and merge those branches. In a traditional software stack with Go, Ruby, Python, or Node.js, deployments to production are easily managed using Git because you are never editing the production code directly on the server.
However, Salesforce, by design, encourages people to edit directly on the “server’. (We’ll explain why this is actually a feature of Salesforce. Ultimately, it’s also why you need to slightly tweak Git to work with Salesforce teams).
Salesforce DX starts with the idea of source driven development. This is excellent. However, the implementation details haven’t quite worked out. The problem is that no matter how much you say that source control is the ultimate source of truth, if people can make changes on the org directly, the org ultimately represents the true picture of what’s going on.
This is all by design of course. Salesforce is great because so many people can make changes. It’s the number one Enterprise CRM because it doesn’t take a CS degree to build amazing software applications. We work with teams every day who are building robust, practical systems that will in many cases be in place and run for 10 or more years. That is amazing.
And Salesforce doesn’t get enough credit as a platform for being able to support that kind of development. There is a reason you don’t want to build your own CRM from scratch using Node.js with React and Go and PostgreSQL. You want to have a system that can be administered by business users and that just works and is up and running all the time.
Given this, it can be difficult to ensure that what is living in source control accurately reflects what is happening on the org. This is just reality and we’ve seen it time and time again. As long as there are changes that can be easily made directly in the org (for example, adding a field is always just easier to do in the Salesforce setup UI and most teams work this way).
There is another factor that prevents a separate Git repository from being a good choice for a source of truth in Salesforce - it does not fit in with the mental model that most Salesforce teams employ today.
Instead of making it easy to work in the Salesforce UI where they can work quickly, efficiently and safely DX encourages teams to learn to use Git - a notoriously confusing command line based tool that even the best devs struggle to use.
It also introduces a new style of org - the Scratch Org. We were really excited about this at first, but scratch orgs are too limited in their functionality and don’t play well with traditional full copy sandboxes and orgs. It even requires the use of a new directory format which makes scratch orgs incompatible with sandboxes so teams cannot smoothly transition especially if they have years of legacy code and metadata.
It seems a bridge too far to ask Salesforce developers and admins to abandon their traditional ways of working in order to adapt a confusing command line based flow.
Despite these limitations, many teams have persisted in building CI and DevOps pipelines for Salesforce with mixed results. It is certainly possible to build an approximation of a CI pipeline for Salesforce using Jenkins and Git and the Ant migration tool or even Salesforce DX.
The problem is that even when you get it somewhat working, the maintenance costs are quite high relative to the benefits you are getting.
Just building the pipeline takes a significant investment of time and resources. Based on interviews with our customers and one of our developers who built an in-house Salesforce DevOps tool, we expect it to take at least 3-6 months to even build the pipeline overall. This removes valuable Salesforce resources away from actually delivering value to customers.
Furthermore, to support a system like this requires a full time DevOps resource to maintain the system and debug it. We’ve worked with large Salesforce orgs who came over to Blue Canvas because they were having to spend too many hours maintaining their Jenkins implementation for Salesforce to the tune of hundreds of thousands of dollars in salary per year. Yikes.
And to cap it all off, there is the tremendous cost of having to train your team to use a new process. And when the tooling is difficult to use and doesn’t fit your teams flow, it becomes like an expensive, leaky sieve. You’re pouring money into the system but there are holes all over it and so many of the benefits that you hoped to recoup with your investment are lost in the process.
This might be the most painful thing we’ve heard from teams. It’s hard to see something that you spend good time and money on that actually makes sense as a good investment, but then to have it sabotaged by poor workflow fit and adoption.
Our customers who previously had CI pipelines with Jenkins or Bitbucket pipelines tell us how frustrating it was to have invested in a system like that only to have it fail when it was most needed.
Ultimately, the reason we have DevOps and source control in place is to allow teams to release higher quality code faster. A good Git based flow and release management strategy is there to:
The usability problems with Git Flow and Jenkins and Salesforce DX make these benefits too difficult to realize.
The reason SFDX doesn’t work is that it tries to bring the things that work in other domains and platforms, without understanding the core differences that exist between Salesforce and other platforms.
Blue Canvas solves the fundamental source of truth problem by automatically mirroring the Git repo with what is in the org. Whenever a developer or an admin clicks “save” we automatically commit that change into Git on behalf of the user. This means that whatever lives in source control is an accurate reflection of what is in the org.
We also allow developers and admins to create simple “pull requests” in the Blue Canvas UI that provide change-set like functionality. We tie the deployment or change set to Git so again there is continuity between the source of truth and the deployment status. It works much the same way as a Heroku deployment works.
This also gets around the usability problem. Instead of asking admins and developers to learn a new process with Git, we are able to fit into the existing Sandbox based development strategy that teams want to be using.
By solving these two problems we unlock the benefits of adopting a modern DevOps tooling for Salesforce. We exist to make Salesforce developers lives easier. We believe that innovation requires fundamental changes to the technologies underlying the process of release management.
By leveraging DevOps best practices and tooling under the hood (such as Git) we have the ability to rollback to previous states and create a great developer experience without requiring the developer to learn a whole new set of tools. We also leverage Salesforce DX itself so your team doesn’t have to.
And ultimately good tooling is about simple and elegant design. Achieving this kind of design has taken work from some of the best minds in the developer tooling industry.
Much like GitHub putting a nice user interface on top of Git, Blue Canvas has the simple mission of making the goals of Salesforce DX and DevOps available to Salesforce teams in a way that actually works for Salesforce developers and gives them access to the best tools on the planet.
.png)