What is Salesforce DX?
My two main takeaways from what I saw were:
- Scratch Orgs: There will now be a quicker, more disposable way to set up sandboxes and you can configure which parts of your org copy over.
- Continuous Integration: There is now a focus on Source Control and actually using it to drive the development process. I believe there will be a CI aspect to the DX program.
That take is certainly reinforced on the Salesforce Developers Blog in Salesforce DX = UX for Developers:
One of the most important changes with Salesforce DX is that, by externalizing more of the metadata and the org shape, we can shift the app’s “source of truth” from the Salesforce org to a version control system. This standard source-driven development approach has been used by developers for years, and it’s now a core part of the Salesforce developer experience.
Another key innovation for Salesforce DX is something we call the scratch org. The scratch org is a brand new org type built specifically for developers and automation. It’s ephemeral, built quickly from your source and metadata, and makes it easy to build your app consistently over and over again, which is great for team collaboration and test automation.
It’s worth noting that scratch orgs aren’t a replacement for sandboxes. Sandboxes are an important part of the larger development lifecycle, and work with our new source-driven development process as the destination for packages built directly from source. All sandbox types, from developer to full, offer the ability to act as user acceptance testing (UAT) and staging environments of the production org.
I’m also really excited by the Salesforce Environment Manager, a tool we’ve created to make it easier to manage the orgs you use as part of the development process. Most of these orgs will be scratch orgs, but it also allows you to manage your sandbox and production orgs. Furthermore, the Salesforce Environment Manager makes it easy to attach your orgs to Heroku so that they can participate inside of Heroku Pipelines, our continuous delivery tool.
Another piece of what they are delivering is an upgrade to the Force.com IDE, and while I wouldn't call it a main takeaway, it was another area of emphasis at their booth that you will now be able to access hover text documentation on many (all?) components during development, at least through Eclipse.
There is also a product page set up that lists some more information:
Source-Driven Development
Salesforce DX delivers seamless integration with Heroku Flow, supporting automated deployments off of GitHub repositories; application pipelines that streamline development, staging, and deployment to production; and a tightly integrated test suite to support continuous integration. Salesforce DX also enables developers to plug into third-party test and build automation tools.
Continuous Integration and Delivery
Enable developers to plug into third-party test and build automation tools for continuous integration and continuous delivery. Salesforce DX also delivers integration with Heroku Flow, supporting automated deployments off of GitHub repositories; application pipelines that streamline development, staging, and deployment to production; and a new test suite to support continuous integration.
Developer Tools
Salesforce DX is an open and standard developer experience, letting you build with the tools you love including Git, Selenium, Eclipse, Sublime, and more. Salesforce DX includes an updated Eclipse integrated development environment (IDE) that significantly expands the value of the toolset to developers.
Scratch Orgs
Salesforce DX introduces a new type of Salesforce environment, the scratch org, a source-driven and disposable deployment of Salesforce code and metadata. Scratch orgs are fully configurable, allowing developers to emulate different editions with different features and preferences, playing a critical role in driving developer productivity and collaboration during the development process. They can also be used as part of automated testing and the implementation of a full continuous integration suite.
A New Command Line Interface
Leverage a new Salesforce Command Line Interface (CLI) across the entire Salesforce platform. Salesforce DX allows developers to easily create environments for development and testing, synchronize source code, create and execute test suites, and control the full application lifecycle from the CLI.
Reimagined Packaging
Salesforce DX moves away from the traditional concept of changesets by reimagining how packaging can be done for Salesforce applications. ISV partners and enterprise customers can now build multiple artifacts to streamline the packaging, deployment, and maintenance of custom software built on the Salesforce platform.
I've written a reasonably extensive blog post on what SFDX is, what it isn't, and some of the deeper implications of it. Disclaimer: I work for Gearset on a deployment / ALM tool for Salesforce, so there's a section on how it intersects with what we're doing, but the post will definitely give you another perspective on the new stuff (and hopefully it's not too spammy - the SFDC folks have been retweeting it at least!).
To briefly summarize my thoughts here though:
What it is
SFDX is fundamentally a mindset or a philosophy. To support this new philosophy, it also includes a series of new tools and features, which can be chosen and composed to build out a workflow that's right for your team, as will hopefully become clear if you read on! It's also a good thing - particularly if you're a developer, but going forwards it'll be a big positive step for anybody building on top of the platform.
A new philosophy: The platform hasn't traditionally been geared towards attracting and retaining the more traditional style of developer. Sure, there are plenty of us working on the platform, but its empowerment of the less technical to achieve great things with ease has been a bigger factor in its success. Compared to other ecosystems the dev experience is lacking. SFDX is an explicit acknowledgement of that, and takes steps towards providing more of the sort of tools traditional devs have grown accustomed to, so the platform remains (and becomes more of) a viable platform for more dev-dependent applications. At the core of this is "version control as source of truth". Following industry best-practice observed across pretty much all other ecosystems, SFDC are stating that the production app itself shouldn't be considered the authoritative representation of an org. Instead, the org's metadata should be version controlled, and the org should reflect this representation, rather than vice-versa. There are some new tools to help with this:
CLI: There's a new sfdx CLI that mostly combines functionality from the force CLI and Ant, but there are some cool new bits, namely data importing straight from a .json file and commands to manipulate scratch orgs. It's built on top of public APIs and it'll be open sourced, so you can expect to see it grow more useful with time.
Scratch orgs: A new feature - using the CLI you can spin up an ephemeral org with arbitrary configuration and push metadata and data to it. This is probably the killer feature in enabling a more traditional dev workflow, and "version control as source of truth". You can spin up an org from your version-controlled metadata in a few seconds, so you'll likely no longer need to try to keep a DE org in sync with your git feature branch - instead you can create and destroy these orgs with abandon with a single script.
CI-enabling features: Heroku Flow will support orgs as target environments going forwards. This means it should be possible to build out a deployment pipeline that can take changes from your VCS and promote them between environments. This is targeted at replacing the current de facto (when it comes to free CI tooling) A neat feature is that PRs will automatically create review apps, so when you're content with the state of your branch, there will always be a running representation of it in a scratch org.
Force.com IDE: From what I've seen the changes here mostly look like a few convenience buttons that map directly to CLI calls. That's cool in it's own right, though.
There's been some talk of new packaging, but I haven't seen / heard enough of it yet to be able to offer an educated opinion. Given that a lot of this seems underpinned by the metadata API, and at any rate is restricted by the underlying structure of the metadata, I'm not sure how far this stuff will go towards solving some of the existing problems with building deployments. This may seem a bit cynical on the surface - "you would say that, given who you work for" - but in actuality this is because at Gearset we spend a lot of time looking at how metadata is interdependent, the myriad modes of deployment failure, and how to mitigate them. Hence...
What it isn't
- Available yet (and afaik there's no release date, currently)
- A solution to your current modes of deployment failures - I link to a bunch of examples of the sorts of things I mean in the blog post, but think missing dependencies, master-detail relationships, history tracking, multi-currency support, deploying flows, API versioning... and so on :) Heroku CI looks like it'll be a great improvement over Jenkins + Ant for most purposes, but you'll still need to make sure that those packages you're building are deployable between environments, otherwise you're just automating deployment failures. (Shameless plug: Gearset makes it much easier to build deployment packages)
- For everyone - the clue's in the name! It's firmly targeted at the more traditional developer. It makes it easier for devs to version control their metadata and generally lead happier lives, but there's no provision for helping the less technical folks work from version control. (Shameless plug: Gearset can help with this)
Going forwards
- I'd expect to see more shops version controlling a wider range of their metadata.
- I'd already expected to see a decline in the use of Jenkins and other more all-encompassing CI servers in shops that are specifically SFDC-focused, because in a the majority of cases they aren't necessary and they're just more infrastructure to manage. Heroku CI will join the other SFDC-centric alternatives like Gearset (shameless plug!) and Bitbucket pipelines.
- I expect to see lots of love for scratch orgs in the community and amongst third-party tools vendors - IDEs spinning up your instance when you hit F5 and attaching a debugger, CI tools using them to build branches, and lots more. I know we're planning some cool stuff with them :)
- There might be some cool innovation around the CLI and integration with the Force.com IDE given that these will be open source and built on top of public APIs, but this is a little harder to predict given some of the... idiosyncrasies of these APIs.
- With that in mind, I expect there will be improvements and expansions to the tooling and metadata APIs going forwards, but some of the issues we face are really down to the structure of the metadata itself, which has more inertia.
Alright, not as brief as I'd expected - hopefully useful though (...and not too self-promotional)! :)
Edit: This post still gets quite a lot of interest a few years on - I wrote a whitepaper on DX towards the end of last year, covering what it is, why it exists, who it's for, and where it's heading in a bunch more detail. I've tried to avoid making it spammy or salesy, though it mentions Gearset a few times, naturally. You can download it here, it's free, no email address required etc. :)