With Salesforce DX, the SaaS CRM giant is taking a leap into the modern development world.
As developers, we’re living in an odd world these days. We’ve got good old-fashioned code. We’ve got low code. And we’ve got no code. And all together they add up into applications.
At one end of the extreme, we have tools like Visual Studio, the epitome of the ‘code first’ development environment. But with its tools for building declarative XAML user interfaces, and its support for Microsoft’s new Template Studio, it’s bringing aspects of the two other development paradigms into Windows development.
At the other end is Salesforce, which has long been the home of declarative development, with a touch of code for advanced customization.
But over the last few years, as it’s absorbed cloud platform Heroku, priorities have changed. Partly that’s because enterprises have adopted continuous integration tooling, developing custom toolchains that cover the entire software development lifecycle. It’s a change has left Salesforce outside the loop, with its own IDE and its own development methodology that can’t be captured by tools like Chef or Ansible and managed by Jenkins or Travis CI.
It’s been a difficult gap for a company like Salesforce to bridge. For one thing, it’s long been associated with marketing slogans that tout its «no software!» approach to applications and services. But that marketing drive has been balanced by the increasing popularity of its low code Lightning development environment, with more and more of its sales and marketing audience developing their own apps — an audience that’s being empowered by Salesforce’s gamified Trailhead training platform.
And, if the crowds at its TrailheadX event in San Francisco were an example of its audience, it’s clearly already across that gap. And not just one way, either. Traditional developers are building apps that work with its APIs (with over 50 percent of all transactions driven from outside its SaaS platform) , while Salesforce admins are using Trailhead to pick up Lightning skills and to learn how to use Salesforce’s own scripting platform.
Heroku is at the heart of Salesforce’s developer model, and its tooling is the basis of Salesforce’s new Salesforce DX platform. Announced a while back, it’s now in public beta for all Salesforce customers, bringing together Salesforce’s web- and Eclipse-based tooling with your own preferred toolchain — with a focus on modern code-first development and DevOps processes.
Perhaps the biggest change is one that reverses one of the foundations of the Salesforce development model. Until now, code has never left the Salesforce platform. Sure, you could write procedures and Apex code in any editor, but much of your work had to be inside the cloud service, with no way to export and manage table definitions or workflow. Everything was wrapped in Salesforce, deployed in ‘orgs’ and driven from the web.
Now, with Salesforce DX, everything is different. A new command line interface gives you the tools you need to work with your choice of tooling, with the ability to take a Salesforce org description and store it in your choice of continuous integration pipeline. There’s also a new tool in the shape of quick to deploy scratch orgs as a new development platform for your code; keeping it separate from the rest of your Salesforce deployment until you’re ready to go live.
The model that Salesforce has shifted to is a familiar one, the modern software development lifecycle, with its focus on a continuous integration toolchain that runs from requirements capture to configuration management to version control to test and delivery, with a side order of operational tooling to close the loop once your code goes live. There’s even Salesforce code in Github, ready to help you get started quickly. You can also start with existing apps, converting them to use with Salesforce DX’s command line tools.
The command line is at the heart of Salesforce DX, as it’s here you’ll create scratch orgs and manage code. It’s a relatively simple CLI, with a basic command grammar, with namespaces for common functions. As it runs as an application, you can call it from any terminal — on macOS, on Windows, or on Linux. It’s also able to run inside many IDEs, for example in Visual Studio Code’s built-in terminal or inside Eclipse.
Scratch orgs aren’t a complete copy of your Salesforce instance, but they can contain enough data and structure to test code. They’re described by a JSON definition file, so you can create them programmatically and store your definition file in a version control system, for when you need to quickly set up and tear down orgs for testing purposes. The config file also controls what features are available, so you only deploy the Salesforce elements you need for the project you’re building. You can populate data using a query on another org, either a full Salesforce instance or another scratch org. Exported data is stored locally as JSON, ready for use in fresh test and dev scratch orgs.
Once you’ve deployed a scratch org, you can then open it in using Salesforce’s built-in development tools or using your own IDE. The Salesforce DX CLI comes in handy here, as it includes commands that open Salesforce’s tooling at specific pages. You’ll also use it to manage files and classes, ready for editing in your usual code editor. It’s also how you’ll trigger tests written in Apex. Salesforce has provided instructions for integrating the Salesforce DX CLI into both Jenkins and Travis CI, making it part of any existing continuous integration tooling and workflow you have in place.
Apps are built as projects, packaged using XML files for the various custom objects in your application. These are stored in a local directory on your dev system, which can be replicated in a CVS like Github. This structure includes the code for Lightning apps or for Apex, as well as images and other assets you’re using. Code can be pushed to a scratch org using the CLI once you’ve made changes, ready for testing.
Once code is finished and ready to deploy, you can either build it as a managed package for use in Salesforce’s AppExchange marketplace or use Salesforce’s APIs to push code into your own production org, ready for use.
