Best Practices

Salesforce Developers Need a Source Control Solution

After interviewing dozens of Salesforce developers, here is what we learned.

Harry Williams

October 7, 2019

Table of Contents

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 ❤️

Force.com is a powerful development platform. It enables engineers across the world to build great applications that enable others do their best work. Salesforce developers can use tools like Visualforce, Lightning and Apex to leverage much of the great functionality offered by Salesforce like Chatter, workflows, triggers and other capabilities. Apps built on the Salesforce platform benefit from Salesforce’s uptime, security and reliability.

Unfortunately, many Salesforce developers face barriers to getting their work into the hands of users quickly. Worse still, many Salesforce developers must go to Herculean lengths to ensure that their work is of the highest quality.

Over the past few weeks, we at Blue Canvas have been talking to dozens in the Salesforce developer community about the barriers and challenges they face. Below are some of the most common issues that we’ve heard about:

ONE: COMMUNICATION BREAKDOWN

One of the most common issues we’ve heard is that teams run into trouble collaborating on the same project. Maybe you’ve experienced the same yourself: Suzy updates an Apex class while Joe is working on the same class in the same Salesforce Org. Suzy’s tests all pass so she excitedly uploads her code to production. A few minutes later, Joe does the same and completely overwrites Suzy’s work. Or Joe has an old copy of the project source code without Suzy’s changes, then deploys the old copy to the UAT environment where all of Suzy’s changes get overwritten.

The situation can be even worse when an Salesforce Admin comes along and makes changes through the web interface without checking those changes back into Git. A developer has no way to see that those changes occurred and ends up pushing conflicting changes.

This is especially important for teams working remotely and the scale of the problem increases with team size.

Salesforce provides some best practices for this in their Salesforce Development Lifecycle Guide, but many of the teams we spoke to still run into these issues.

TWO: NO MASTER/SOURCE OF TRUTH

When Joe and Suzy get into this kind of code tangle, there is no system of record to help get them out. It’s nearly impossible for Joe and Suzy to even tell who did what. What changes occurred? Who made them? And when? Joe and Suzy need to manually figure out who changed what.

Some teams are using tools like Github to check code differences, but they are not able to see the differences between the code on their actual production Salesforce Orgs and their source repository. Everyone who has the ability to make changes on the Org must be meticulous about committing their changes back into Git. If just one or two people on the team do not regularly commit their changes to Git then the process breaks down. We heard about issues here from quite a few of the people we spoke to.

Most teams of the dozens we spoke to still rely on a highly manual process for tracking changes. As you can imagine, this caused considerable frustration for many teams.

Too often there are important differences between the repo and the Org. There is no way to see those differences making debugging extremely challenging.

This can be exacerbated for consultants when their customers make changes through the web interface. Few teams have found repeatable workflows that ensure these kinds of changes are tracked in source control.

THREE: ROLLBACK

Whether there is a bug in production due to a collaborative tangle like the one described above or because there was some other difference between the code Salesforce Org and in the source control repo, teams are reporting challenges associated with rolling back to a stable version of the Org.

For most teams, there is no reliable way to quickly rollback their code and return to the last working version while they sort things out.

One developer we spoke to told us a story about being 13 hours away from a demo of a major release. Something went wrong and she had no way to see what breaking changes had been committed or to roll it back. She then spent what she called the “most stressful 13 hours of her life” diligently trying to understand what went wrong and get things working again.

The difficulty with rollbacks is that you have to manually work your way back from most recent through oldest deployment, in the reverse order they were originally applied. Since metadata components have dependencies on each other, a deleted component needs to be restored before an Apex class can be reverted. And while there are any references to newly added components, they cannot be deleted. It gets even more challenging when you have metadata deployed together with manual configuration settings.

FOUR: MANUAL DEPLOYS ARE RISKY AND SLOW

Many teams also mentioned that they have to manually track changes that are made before a deploy. Each team member has to remember to write down each change they made on the Org. They then have to update their package.xml, profiles, permissions, and roles. Unsurprisingly, many teams reported that this manual process was difficult to keep up. Humans err relatively often and teams spend countless hours figuring out what had been missed during the manual change log accounting.

Deploying manually is also painstakingly slow. This presentation from Salesforce themselves on automating deployments for Salesforce Orgs says it can take 8-12 hours to do a deploy. Too many teams are waiting 8-12 hours on Friday afternoons after your sprint demo and finding out that things did not go as planned.

GIT CAN HELP WITH FORCE.COM DEPLOYS

Proper source control for Salesforce Orgs would help with all of this. However, many of the teams we have spoken with have become very comfortable using Git and would prefer to use it as their source control tool.

At Blue Canvas, we believe that Git can ameliorate many of the challenges listed above. Git makes collaboration straightforward and simple. You can use branches for different Salesforce Orgs. Git also acts as a system of record so you can see what changed in your code. Rollback is also straightforward with Git - simply git revert to the last working commit. Furthermore, Git is ideal for seeing code diffs.

Finally, using a push-to-deploy workflow, you can get your deploys down to minutes rather than hours.

We’ll be posting a more detailed look at how Git can solve these issues in our next post.

WE WANT TO HEAR FROM YOU!

Are these the issues you face in your Salesforce deployments? We want to hear from you. Email us at team@bluecanvas.io to let us know what challenges you face while deploying. We have other great ideas for solving these challenges which we’ll be posting about soon!

Try bluecanvas now!

Start your 14-day trial!

Get Started

Made with love by the Blue Canvas team ❤️

Try Bluecanvas now!

Start your free 14-day trial

Get Started

TABLE OF CONTENTS