The 3 Costs of Source Control
Ideally, you will never need an audit log or backup of your Salesforce metadata. Everything will always work smoothly and there will be no issues to deal with or need to rollback to a previous state or recover lost metadata. However, when you do need to do any of those things, you really need them. This is where source control can be a lifesaver.
There are all manner of reasons to use source control on a daily basis: facilitating collaboration between colleagues, handling merge conflicts, serving as de facto documentation for a project, to facilitate continuous integration, etc. But it is when your development team is in crisis that you are going to be happiest that your business has invested in source control.
This is especially true with Salesforce. We’ve talked to hundreds of Salesforce developers over the past few months. Far too many have told stories of one developer overwriting the work of another and some have even lost months of work permanently and forever because they had no backup of their metadata. Having this kind of loss can be devastating to a business and can throw an organization into crisis.
Source control for Salesforce, makes this a far less likely outcome. When your code is managed under source, you have continuous up to the minute backups of your code base ensuring that work is never lost. If you need to roll back your code or recover lost work you can.
Source control is like an insurance policy. Most of the time it’s just there, but when you need it it becomes your most cherished investment. It allows you to know who has changed what and recover work that can be lost.
Like insurance, many teams also think of source control as a cost. There are 3 primary costs that prevent many Salesforce development teams from implementing source control:
Setting Up Source Control
Setting up source control takes time. Assuming that you choose Git, that still leaves the question of whether or not to use a hosted Git solution like GitHub or Bitbucket and which one. Furthermore, it’s not always easy to get Salesforce metadata into Git, particularly declarative changes. This must be done by implementing Ant scripts and setting up a CI server like Jenkins. Creating all of this infrastructure can be costly and time consuming and even then it’s effectiveness is highly dependent on the next two costs.
Training A Team to Use Source Control
You need to train your team to follow best practices and commit their changes into source control continuously. This can be difficult with Salesforce because there are so many declarative users who do not know Git or other source control tools and who may not be interested in digging into the command line. Furthermore, because of Salesforce’s great clicks not code philosophy, it can be very easy to make changes directly in production which are not tracked in source.
Learning Git can be difficult for many developers. Even very advanced developers run into challenges with Git on an almost weekly basis. What is the difference between revert and reset, again?
Maintaining and Adhering
Finally, your source control solution is only as good as your team’s adherence to it. Are team members regularly remembering to commit their changes to source? What if they just do a quick hotfix in production or staging. It’s just a minor and simple declarative change and they’ll just do it this once. If they don’t commit to source control, then your source control and Salesforce sandboxes quickly become out of sync and much of the benefit of source control becomes moot.
What happens with every Salesforce release? What about when there are new API endpoints or changes to the Force.com migration tool? Do you remember to update your scripts in a timely fashion and keep everything up to date and maintained? What if a script starts failing? Do you shut down your development pipeline while you scramble to debug it?
Blue Canvas Removes the Costs of Source Control
Blue Canvas eliminates the three costs above and makes source control for Salesforce very simple. So you’ll look like a hero if you ever need it.
Setting Blue Canvas up with your Salesforce environment takes literally 4 clicks. In just a few seconds you can have all changes in your Salesforce development pipeline tracked in Git.
You don’t need to train your team to learn an entirely new workflow. Instead, Blue Canvas runs as a background process that automatically captures changes to your Salesforce orgs and commits them into a Git repository. Whether the change is made through the developer console, declarative UI or through a text editor like MavensMate, Blue Canvas ensures that all changes are backed up and logged in Git. Your team doesn’t even need to know what Blue Canvas is or remember to commit to source.
And when you use Blue Canvas you have a team working around the clock to make sure your source control system is up to date with the latest Salesforce releases and APIs so you never need to spend developer time debugging and maintaining scripts.
Are you ready?
Is your team protected from crisis mode by having continuous backups of your code and metadata to source control? If not consider investing the 5 minutes it takes to create a Blue Canvas account and go back to not worrying about whether your code is backed up.