During this year’s Dreamforce – Salesforce.com’s annual user conference in San Francisco – Salesforce announced Salesforce DX as a new way for developers to manage and develop Salesforce apps.
In the past, applying the best practices and processes of traditional software development on the Salesforce platform could take a substantial effort. Even after the initial investment of setting up a process and figuring out how to accomplish things like distributed development, version control, branching, merging, and CI, the Salesforce platform has always been more complicated to develop with than other tech stacks. Developers are accustomed to working on tech stacks such as Java/Spring, .NET, and node.js, which have had those processes in place 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.
Salesforce development teams don’t always follow the basic best practices of software development. How often does everyone develop in the same sandbox with no version control? If it were a Java/Spring project, that would be equivalent to all the developers writing their Java code directly on the shared test server and performing their DDL directly on the shared test database. Even when developers each have their own org, it can quickly become inconsistent with version control when they switch active branches.
Enter scratch orgs, which will allow developers to quickly spin up new orgs via a command and JSON configuration. With scratch orgs, there is 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 also has commands for managing the scratch org, so it can be automated.
New Command Line Interface
The command line interface adds additional commands via the Heroku CLI, aka Heroku Toolbelt. This is core to the development experience – it is used by the IDE, and it can be added into any other automated processes such as continuous integration, automated build scripts, or deployments.
Of the existing functionality (e.g. have been able to do for a while by a different means), data loading is of particular interest. One of the best practices is to check in DML, which can be used to share solid test data. This is often overlooked with Salesforce, perhaps because it can be a bit more difficult to automate with the data loader.
Source Control and Team Development
It has been difficult to support concurrent development in Salesforce, 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, for example, a privilege exists in one org but not another. Additionally, profiles only populate with a subset of all the metadata that they could have, because they are dependent on whatever other components are requested with them.
Developers have been waiting for something like Salesforce DX for a while and, so far, it has a lot of potential. Salesforce DX will enable all developers to easily improve how they work on the Salesforce platform.
Want to learn more about Salesforce DX? A more detailed version of this article is featured on Peter’s website.
Visit Salesforce’s website to view the full Salesforce for Developers Keynote from Dreamforce 2016.