Version Control and Salesforce Admins
As soon as Salesforce DX was announced he offered a detailed list of thoughts and hopes for DX and what it means. We love the article because it sums up a lot of the major challenges with Salesforce development and a wish list of proposed solutions. He really caught our eye with this quote at the end:
“I’ve left this for last, but it might be the most important, because everyone must follow the process for it to work. How will admins fit in to source control and continuous integration processes? It is part of a developer’s skill set to use version control tools like Git or SVN and set up CI tools like Bamboo or Jenkins.
If you accept the premise that all metadata changes are code changes and should follow all of the same processes as traditional code changes (i.e., Apex and VF) that Salesforce DX enables then there must be a way for admins to be involved.
It all falls apart if admins make changes in production or make changes in a sandbox and deploy via change set and do not use version control. Because it is so easy to make declarative changes, however this is implemented it must be done in a way that makes it simple for admins.”
This is a real problem and as Peter says it might be the “most important” one facing Salesforce devs and Admins.
Salesforce is great – precisely because you can do so much with declarative changes and code. Many different profiles of people can contribute to make great apps and technological training is not a barrier to entry. Product managers and business analysts who understand the business side of technology are not held back by their inability to code. They instead are empowered to make changes to the application and bake their own knowledge and expertise into Salesforce implementations.
What makes Git and source control great is that it’s a Source of Truth. It allows you to know who has changed what and when on your Org. It allows you to know exactly where you code base is today and, crucially, how it got there. You can use version control to understand how your code base has changed over time.
There is a problem though. The way that Salesforce development works today, these two threads are in constant tension. On the one hand, Salesforce is great because non-developers are unencumbered enough to go and make changes to applications based on their expertise. However, this conflicts with the benefit of source control and Git in that it makes it hard to look at your version control as a source of truth.
As Peter notes, all metadata is code and needs to be tracked in source control. If someone logs into Production and updates a Workflow or Field, and that isn’t captured in source control, you are going to have issues with your CI.
It’s like logging into an old FTP server and making a change directly and not committing anything.
Blue Canvas and Salesforce DX
Blue Canvas seeks to solve this so-called “Admin Problem” for Salesforce DX. Blue Canvas continuously monitors your connected Orgs for declarative changes and commits them into Git automatically. This means that all changes that are made by Admins are now fully tracked in version control and in particular Git.
Developers can then go ahead and use standard Git commands like
git pull and
git diff and
git log fully confident that the Git repository that they are working with includes all changes on the Org. Essentially, Blue Canvas ensures that your version control is actually a source of truth.
Best of all, there is no special training required on the part of Admins. As Peter notes:
“It is part of a developer’s skill set to use version control tools like Git or SVN and set up CI tools like Bamboo or Jenkins. If you accept the premise that all metadata changes are code changes and should follow all of the same processes as traditional code changes (i.e., Apex and VF) that Salesforce DX enables, then there must be a way for Admins to be involved.”
Admins and non-developers have a lot on their plate and the last thing they need to do is learn Git — which can be challenging!
With Blue Canvas, Admins can just go about their day as they normally would making changes as they normally do through the Salesforce UI. Developers can rest assured that those changes will ultimately make it into version control.