The Stack Overflow 2015 Developer Survey highlighted that Salesforce was “the most dreaded” technology to work with. According to the respondents, three quarters of Salesforce developers would rather work with another language or technology. It’s a shame because the Salesforce platform is very powerful and amazing. It allows users to do a tremendous amount of excellent work with limited resources. The Salesforce cloud is secure, reliable, and flexible.
So why the black eye? The developer experience matters! As a platform Salesforce provides high value to companies small and large. However the truth is, over time very little has changed about Salesforce’s developer experience.
Meanwhile, the outside world has changed significantly: API-first development, containerization, conversational development with tools like GitHub and GitLab.
Salesforce has been very innovative on the end-user side with the Lightning UI and the recently announced Einstein AI engine, progress on the developer tooling side has been slow.
Developers want to work with modern tools. The best modern frameworks get out of your way so that you can develop and release features quickly.
Most significantly has been the tremendous shift towards more collaborative development. The vast improvements brought about by tools like Git and platforms like GitHub and GitLab, have fundamentally changed what developers expect. Developers have come to expect that they can work collaboratively.
There is some Open Source activity, but significantly less than most ecosystems.
How can this situation be improved? We’ve been interviewing salesforce developers for the past month and have noticed two major areas that need the most urgent attention: open access to source code via standards-based source control, and dropping the barrier to entry by simplifying deployment.
Today, Salesforce has no system of record for code running in production. Each deploy overwrites previous versions of your Salesforce code. This is problematic because once code is pushed, there is no good way of rolling back. There isn’t even a way to see what has changed from previous versions to the latest. This makes collaboration difficult and debugging a chore.
Many developers are taking matters into their own hands and use a manual Git workflow to provide some semblance of source control to their Salesforce Orgs. A workflow like this generally means that the developer pushes to a Git repo from the same local machine that their code on. It’s a manual process that needs to be followed diligently, or content in the Org and repo will diverge.
Nevertheless, Git is a great tool, and platforms like GitHub, Bitbucket, and GitLab all do a great job of making Git accessible and convenient.
But using Git and a tool like GitHub or Bitbucket leaves other challenges unmet. One of the great benefits of the Salesforce platform is the ability to make declarative changes through the Salesforce UI. This is one of our favorite things about the Salesforce platform and a popular feature for business customers, which allows non-programmers to customize the system. Unfortunately, when changes are made to an Org in this way, it’s all too easy for the code running on the Org to diverge from what you are tracking in Source Control. Companies have built complex workflows (like Atlassian’s) to mitigate this issue, but it remains time consuming and prone to human error.
Handling source control in this ad-hoc and unintegrated way leaves you exposed. Developers and admins can overwrite each other’s changes and there is no way of knowing who did what. Rolling out changes (or rolling them back) is extremely difficult and tedious.
The second major issue that frustrates developers about the Salesforce platform is just how difficult and slow it can be to get your code uploaded and running.
DevOps has become a bit of a buzzword, but the industry shift towards continuous delivery is real and powerful. Software developers around the world are getting closer to a world in which they can write a feature, test it and deploy it in less time than it takes to get a morning cup of coffee. This was once seen as a major competitive advantage – if you could get your code out faster than your competition you would win. Now it’s just seen as table stakes.
Deployments on Salesforce are not easy to automate. Accordingly, many Salesforce teams are not deploying as often as they could be. And when they do the process is slow, cumbersome and manual. The manual nature of Salesforce deployments leaves companies vulnerable to human error. Currently, most teams have a release manager who acts as a gatekeeper for deploys. But it’s up to all members of the team to manually recall what changes they made to the repo and inform the release manager of the changes. As you can imagine this is problematic.
The tooling for deployments is also cumbersome. If you have the patience to set up the Ant Migration Tool, you can automate parts of this, but it requires a significant amount of maintenance and is not all that intuitive to set up. Many Salesforce developers still fire up Eclipse as their go-to tool for deploying.
We believe that a better developer experience is possible. Our solution: implement Git directly with your Salesforce Orgs. This makes collaboration between developers and between developers and admins much easier. You won’t face merge conflicts or issues where one makes changes that break another’s code and deployments are now just a part of your standard workflow. For more information, check out Blue Canvas.