In the fall of 2017, Salesforce became the “first enterprise cloud software company to break the $10 billion revenue run rate” according to CEO Marc Benioff, cracked the Fortune 500, and topped out at number one on two other significant Fortune rankings: Future 50 Leaders and 100 Best Companies to Work For.
What makes Salesforce so successful? Aside from their unique work environment and community giveback initiatives, Salesforce provides a customer relationship management (CRM) experience that is powerful, highly customizable, and easily accessible.
If you attend any Salesforce event, you will undoubtedly hear the phrase “click, not code.” This is the mantra of developing in the Salesforce environment. Salesforce has shifted the power of customization from the developer to the administrator by providing multiple avenues for “declarative programming” — step-based processes that allow someone with no software development experience to create sufficiently complex functionality with a few clicks.
The Problem With “Click, Not Code”
While this declarative programming model is great for those without software development experience, the reality is that developers are using Salesforce. And for many of us, the limitations of a click-to-code framework are cumbersome and frustrating. We need to write custom code; we need to integrate with external systems; we need the ability to track our changes. While Salesforce provides some capabilities to develop in a more traditional manner, their solutions are tedious, insecure, and mostly incomplete—until now.
As part of their Spring 2018 release, Salesforce brought something new to the table: Developer Experience, more commonly referred to as DX. This powerful set of tools is bringing Salesforce up to speed with the world of custom development, allowing users to approach challenges with an agile methodology and solving many of the platform’s previous problems.
In this blog series, we will discuss four of the most common problems developers have had with Salesforce development, and how DX has improved them:
Custom software development
Single source of truth
Metadata management
Continuous integration and deployment
This blog post will address the first topic: How custom software has historically been done in Salesforce and how DX has dramatically improved the process.
The Problem: Apex Development
Salesforce has had the ability to do custom development in Apex, their own programming language, for a long time, but the methodology around that development left much to be desired. Before DX, developers had two possible approaches: write code in the Salesforce Developer Console or develop locally in your IDE of choice and copy/paste changes into the organization (org).
Salesforce’s Developer Console has its merits, but it lacks much of the functionality developers expect from their IDEs, like keyboard shortcuts, autocomplete, and a visible file structure. It is only accessible through a Salesforce org, so it provides no way to develop locally and offline. Additionally, the debugging capabilities of Apex via the Developer Console are lacking, and the logs provided are confusing and ineffective. To its credit, the Developer Console does have fairly intuitive methods for running tests and test suites, as well as the ability to execute “anonymous Apex” in order to quickly test specific snippets of code.
The copy/paste methodology has some obvious flaws, most notably the risks of overwriting someone else’s changes or directly impacting the production org. While this provides you with the ability to develop offline and in a familiar IDE or text editor, it is insecure and time-consuming. Additionally, at the end of the day, you are still constricted by using the Developer Console to validate and save your code. And no matter which approach you choose, you are left without any history of your changes.
The Solution: Salesforce DX
DX centers around the new Salesforce command line interface (CLI); from retrieving metadata, to creating a project, to exporting and importing data, the CLI is a necessary tool to improve the speed and efficiency of a Salesforce developer. Using the Salesforce CLI, developers now have a solution to some of the major Apex development drawbacks previously mentioned. First and foremost, this effectively eliminates the need to develop directly in the Developer Console, as you are able to create a project with a familiar structure, populate the project with desired Apex classes, and deploy the code directly to a Salesforce org. This ability to deploy to an org also means that developers no longer need to use the copy/paste methodology that is all too common in the Salesforce world.
Not only does DX make deploying code much easier, but it also provides the ability to retrieve code from a Salesforce org and store it locally on your own machine. This allows a developer to work on and update previously written code locally before directly making changes in the org itself.
Finally, with the ability to create projects, DX introduces structure to custom development in Salesforce. Though this may seem like a small improvement, it is significant. In a Salesforce org, all Apex code is lumped into one place, making it difficult to distinguish which classes are supposed to be grouped together. DX gives the developer the ability to modularize the Salesforce org, splitting it up into discrete projects that provide order to what has previously been chaos.
The Drawbacks to Salesforce DX
With the introduction of DX, Salesforce has narrowed the gap between Apex development and standard development; unfortunately, a gap still remains. One of the most noticeable drawbacks is the lack of consistent and comprehensive autocompletion capabilities. DX alone does not provide context awareness, which can make development a tedious trial-and-error approach. To mitigate this, Salesforce also released free, supported plug-ins for VSCode that provide much of the functionality and convenience expected from a modern day IDE. However, while the plug-ins assist with context awareness, it is still difficult to maintain an accurate list of terms for autocompletion, as each Salesforce org has a unique set of metadata.
Another serious drawback is the limited ability to debug Apex code. There currently exists the “checkpoint” method—the Salesforce version of breakpoints—but this is not debugging so much as it is extensive logging. This means that you cannot actually step through your code, but can only look back on code that has already run and view variable logging at the specified checkpoints. Apex development could be greatly improved if more robust debugging capabilities were available.
Finally, with DX alone there is no way to manage any sort of code conflict, so the most recently deployed code always wins. This is probably the biggest drawback of the traditional org-based development model used in the Salesforce world to date. However, DX opens the door to transition development from the org to a source control repository. If you are an experienced developer, this may seem like a given; but for Salesforce developers, this is huge.
Next Time
We’ve focused here on how DX has improved writing custom Apex code, but what about managing those changes via source control? And wouldn’t it be nice if you could also track the changes made to an org through declarative programming? For our next installment in this series, we’re going to dive into the Salesforce methodologies for the source of truth: How it has been done historically, and how DX has changed the game. We’ll also introduce Scratch Orgs, one of the biggest features of DX, and discuss how they give developers control into effectively managing metadata.
Looking for help with Salesforce development? Reach out to us at findoutmore@credera.com. We are practitioners, not salespeople, so you’ll speak with an actual Credera consultant. We look forward to chatting to see how we might be able to help.
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
