Salesforce DX was announced at Dreamforce 2016 as a new way to manage and develop Salesforce apps. It is a new and much improved Salesforce Developer Experience. The rest of this article consists of my thoughts on platform development in the past, the future with Salesforce DX, and some of my hopes for Salesforce DX based on my experiences and what I saw at Dreamforce.
To be frank, trying to apply best practices and processes of traditional software development on the Salesforce platform has always taken a substantial amount of effort to set up. Even after that initial investment of setting up a process and figuring out how to shoehorn in things like distributed development, version control, branching, merging, and CI, it has always been much more complicated to develop with than other tech stacks. Developers are used to working on tech stacks such as Java/Spring, .NET, node.js, that have had all of that figured out for a long time.
Salesforce DX is the solution to those problems. It will standardize a set of tools, APIs, and best practices for development on the Salesforce platform. The goal, as I see it, is to make it inexcusable to not use best practices we software developers have been using on other tech stacks for years. This will have a positive side effect of attracting and keeping other talented developers on the platform.
A New Command Line Interface
The new command line interface adds additional commands via the Heroku CLI (a.k.a. Heroku Toolbelt). This is core to the development experience. It is used by the IDE. It can be added into any other automated processes such as continuous integration, automated build scripts, or deployments. I believe a solid command line is core to everything. Give the developers a rich and complete set of basic commands and they’ll use them and come up with new, better, unexpected ways as well.
Of the existing functionality (i.e., have been able to do for a while by a different means), I am particularly interested in the data loading. One of the best practices is to check in DML which can be used to share solid test data. I see this overlooked with Salesforce all of the time, perhaps because it can be a bit more difficult to automate with the data loader.
- It will be easier to incorporate test data into development processes
- Other devs will add in commands that they’ve been using in their own orgs
- Other devs will improve the existing commands
- The CLI will be extendable, but grow only as needed
This was the most intriguing concept I wanted to learn about. Some shops/teams/projects do not follow basic best practices of software development. How often does everyone develop in the same sandbox with no sort of version control? If it were a Java/Spring project it would be equivalent to all developers writing their Java code directly on the shared test server and performing their DDL directly on the shared test DB. Even when developers each have their own org, their org can quickly become inconsistent with version control when they switch active branches.
Enter Scratch Orgs. They will allow you to quickly spin up new orgs via a command and JSON configuration (This is also good for easily spinning up an org for a feature test such as multi-currency). With scratch orgs, I see a natural fit to a feature branch workflow. Branch for your feature. Spin up a Scratch Org. Deploy to it. Develop in it. Finish. Delete the Branch. Delete the Scratch Org. The CLI has commands for managing the scratch org, so it can be automated.
- It will be easy to create Scratch Orgs that are identical or similar enough to production (export config?)
- Scratch Orgs will be able to be created very quickly and built to (compiled) very quickly.
- Developers will be able to use the interactive debugger in Scratch Orgs for free.
- There will not be a need for any more manual changes such as Flow deployments. The Scratch Org will be spun up and ready to go with zero need for manual changes, once data is automatically loaded.
The Force.com IDE has been updated to include many new enhancements. The CLI will be central and able to be run from the IDE. The App Builder will be able to be used directly from the IDE (looks like it opens in a web tab of sorts). The metadata will be sync’d up with the org automatically. It looks like there is some code completion as well. Since it runs in Eclipse as a plug-in, direct integration with a version control system can be done.
- Code completion works on all things
- Real-time syntax checking
- Transparent or very simple syncing between the local file system and the org
- That there is good code navigation, e.g., click to go to declaration, find references to, etc.
- Refactoring Support will at least support the Java refactoring functions in Eclipse
- All of the functions will be available via the API
- All of the functionality in Eclipse could be implemented by other IDEs (should be able to as IDE is open source)
- Static code analysis will be supported (BTW, a new Apex compiler is coming!)
The idea of this is that somehow developers will be able to organize their code and orgs better through new packaging features.
One of the biggest pain points in Salesforce development is its lack of code organization through namespaces or Java-like packages. There is one large src/classes directory that has all of the classes in an org. Another pain point is that there are no well-maintained popular open source libraries, which is largely true (I know about fflib, which is great, but there’s more than that needed). Each org needs to create its own Math/String/Lang/Etc utils classes, its own zip, own csv parser (my co-worker pointed that one out), its own dynamic soql utilities class, etc. In other languages this stuff exists and every org doesn’t reinvent the wheel, they just use their package manager (mvn, npm, etc.) to get what they need.
The fact that this packaging problem will be addressed is huge and I am hopeful it will solve all the packaging related issues.
- It will facilitate more open source libraries.
- It will lead to a better way to organize code.
- Dependencies will be handled well
- Rollback or version switching will be implemented
- Salesforce will release some of their own common code such as utils classes as part of packages and lead the support of them
- All of it will be available via an API
Source Control and Team Development
Changes are being made to make it easier to use version control and efficiently develop with teams of developers.
Traditionally Difficult Files
It has been very difficult to support concurrent development, especially more than one project at a time, when profiles are being modified. Different orgs have different configurations, were created at different times, or have other aspects that cause profiles to end up not working (e.g., a privilege exists in one org but not another — compile failure). Additionally, profiles only populate with a subset of all of the metadata that they could have, because they are dependent on whatever other components are requested with them.
Scratch orgs start from scratch, so don’t need to worry about destructive changes, but production doesn’t start from scratch and larger development efforts may have a more than a few destructive changes. If we are building from source at a point in time, my hope is that destructive changes can be added in some way that works well.
I’ve left this for last, but it might be the most important, because everyone must follow the process for it to work. How will admins fit in to source control and continuous integration processes? It is part of a developer’s skill set to use version control tools like Git or SVN and set up CI tools like Bamboo or Jenkins. If you accept the premise that all metadata changes are code changes and should follow all of the same processes as traditional code changes (i.e., Apex and VF) that Salesforce DX enables then there must be a way for admins to be involved. It all falls apart if admins make changes in production or make changes in a sandbox and deploy via change set and do not use version control. Because it is so easy to make declarative changes, however this is implemented it must be done in a way that makes it simple for admins.
- It will be simple for admins to make changes that conform to the Salesforce DX processes
- Managing profiles will be transparent or very simple
- All changes will be available via the API, so that no manual changes will need to be done during a deployment
- Destructive changes will be handled elegantly.
Developers have been waiting for something like the Salesforce DX for a while and so far it looks like it is going to be great. Salesforce DX will enable all developers to easily change how they work on Salesforce platform for the better.