SalesforceDX — View from the Coal Face
At Dreamforce 2016 Salesforce announced the Salesforce Developer Experience, aka SalesforceDX, which promises major enhancements to the development lifecycle with Salesforce.
SalesforceDX is a collection of tools to make developing on the Salesforce platform easier, and more in keeping with the way that enterprise software is developed for other platforms.
SalesforceDX Features
New Force.com IDE
The Force.com IDE has had some love recently, with Lightning Components finally supported after being GA for around 2 years! It still lags too far behind the org capabilities, so hopefully SalesforceDX will improve this.
The new IDE will be tightly integrated with the new CLI (see below) and the org that is being developed, so we should be able to access functionality from the Salesforce org direct from the IDE — hopefully things like previewing Visualforce and Lightning App pages, rather than switching between the IDE and the Salesforce UI.
We’re also promised that synchronisation between the IDE and the target org will be a lot more granular than it has been. Deploying to the org will only send up aspects of metadata that have changed, so if you add a field to a custom object, for example, only that field will be sent to the org. The same applies to deploying to the org — only changes from the local filesystem will be pushed up. For those familiar with GIT, this is a similar concept to staging hunks of a file rather than staging the entire file regardless of whether much of it has changed.
Scratch Orgs
This is probably the area that I’m most pleased about. Being able to spin up an org on demand is something we’ve had for a while, via the environment hub for partners or a new developer edition. Where things slow down is enabling features, which involves raising a case with Salesforce support and then receiving a call to repeat exactly the same information that you’ve already put in the case. For our BrightMedia development environment we have to get the Apex character limit increased before we can deploy our codebase which always adds a few hours to the process.
Scratch Orgs are potentially short-lived orgs that can be created with specific features enabled declaratively. Thus we’ll be able to create a fresh org, set up the features as required, install and test our code out of version control and then drop the org. I haven’t seen anything around how we will actually drop the org as yet, but I did hear some statements in Dreamforce sessions that the orgs can disappear at any time, which makes it more important than ever to commit your work. I assume at any time doesn’t mean it will disappear from under you while you are half way through writing a new method!
Scratch orgs can also have namespace, so as I understand it this will allow developers to share the same namespace across multiple orgs which will make developing packages for the app exchange much easier.
Scratch orgs sound great, but I don’t think that I’ll be moving all of my development over to them. Usually my dev orgs have a lot of data that I’ve set up intermittently over time and can’t replicate without some effort, so I’ll be keeping a few of those going. What it will allow me to do, in addition to automated testing etc, is set up new developers with a minimum of fuss an effort.
New, Improved CLI
Anyone who reads my blog knows that I’m a big fan of the existing Force CLI.
SalesforceDX brings a new CLI, combining the Heroku toolbelt with the Force CLI and introducing some new commands. I’ve read a few posts about how the new CLI will allow data to be loaded into an org, but the existing CLI supports that through the record create:bulk, so I guess that shows that some of the people excited about SalesforceDX haven’t been using the existing tools to their full capability.
One thing the new CLI does provide is the capability to create and configure scratch orgs from the command line, allowing this to form part of automated processes such as a continuous integration build, deploy and test.
Another feature I really like is that the new CLI is based on a pluggable architecture, so anyone will be able to add commands and potentially publish them out to the wider community. This means I’ll have the option of extending the CLI with commands specific to my BrightMedia processes, rather than the current situation where I’ve built my own that leverages the Force CLI as and when it needs to. It also runs on Node, which is handy as I’ve just rewritten my BrightMedia CLI tool in JavaScript on Node!
Heroku Flow
I haven’t spent a huge amount of time investigating this, as a number of the features appear to rely on Github integration, whereas we use a different cloud provider for source control.
The key feature that is more generic is pipelines, which should allow continuous delivery workflows to be defined. This is the kind of thing that many of us have been rolling our own solutions to for years, using tools like Jenkins and Bamboo, or building from scratch with command line scripts. I’ll be watching how this progresses with interest!
What this means for developers
SalesforceDX is undoubtedly good news, but it’s not available as yet so for now it’s an aspiration. Salesforce usually take an iterative approach to most new features, so I’d imagine it will take a few releases to have all the features that we feel we can’t live without in place.
I’ve been critical of the developer tooling in Salesforce for quite a while now — having to bounce between tools (some official, some community provided) based on what type of development you are carrying out is something that makes developers from Java or .Net world roll their eyes and doesn’t exactly scream that Salesforce is an enterprise class development platform. We all get that one of the USPs of Salesforce is the fact that you can build simple applications and process automation through declarative tools, but large-scale implementations and app exchange products typically require quite a bit of custom development and at times it feels like the current tooling makes things harder rather than easier.
The most important aspect of this to my mind will be how it is priced. As a general rule developers don’t pay for anything, ever. If the SalesforceDX team can get this through the bean counters as a free offering I’m sure it will see huge take-up—you only have to look at how successful the free Developer Edition has been over the years. A freemium model would probably work quite well, allowing us to start out with the basics for nothing and then paying once we consume a larger number of scratch orgs or set several automated workflows.
If SalesforceDX is pay to play from the word go, I fear it stands a chance of having a low take-up and withering on the vine — after all we’ve been building our own solutions to this for years now and we can continue in this vein. It’s always hard to ask for an investment of time and money when the outcome is that we’ll be in exactly the same place but using someone else’s tools rather than our own.
Tell me more
If you want to know more about SalesforceDX, the best place to start is the official site.
If you have questions, tweet them with the hashtag #SalesforceDX — the product team are monitoring this and my experience is that they do respond and in a pretty timely fashion.
I’m better known in the Salesforce community as Bob Buzzard — Umpteen Certifications, including Technical Architect, 5 x MVP and CTO of BrightGen, a Platinum Cloud Alliance Partner in the United Kingdom who are hiring.
You can find my (usually) more technical thoughts at the Bob Buzzard Blog
