Though TrailheaDX ‘18 was a bit more muted than Dreamforce ‘17 or even TrailheaDX ‘17, it was still a great conference. Salesforce has been pushing a lot of changes for developers over the past two years, and the conference represented a good opportunity to catch our breath and hear the latest about Salesforce DX.
Wednesday’s Salesforce DX keynote was especially enlightening. Since we couldn’t find a video online, we thought we’d put our notes here for others to find. Hopefully, Salesforce will post it soon. We’ll also take this as an opportunity to include some outsider commentary about how we see the state of DX right now.
Adoption Adoption Adoption
Salesforce SVP Wade Wegner’s opening remarks touched on a theme that we heard elsewhere in the conference: Salesforce DX adoption has been surprisingly low. Wade addressed it directly in the keynote. We talked to friends and partners in the expo hall who mentioned it repeatedly. And we hear about it from customers every day. Though people want to move to Salesforce DX, it is proving difficult.
A big part of the problem is that moving diverse teams to source driven development is a bigger task for many companies than expected. Also, DX makes some big requests: it asks users to break up what are in many cases ancient legacy monoliths into a smaller and more modular directory structure. Like eating your vegetables and avoiding sweets, this is a good idea in theory, but proves much more difficult in practice.
Very few customers that we speak to have successfully adopted DX. So if your team has been struggling, the keynote confirms that you are not alone, and you can feel at least a little bit better about that.
Fortunately, the DX Keynote also offered a plan to help. Much of the talk was structured around the idea of providing more ways for people to be successful with DX.
Adoption of Source Driven Development for Salesforce
We really admired how upfront and direct Salesforce was in this keynote. It provided yet another example of Trust and reminds us why Salesforce is such a beloved brand: they usually provide straight talk at the highest levels.
The first thing they said is that improving the Metadata API and adding support for more Metadata types was a high priority. A new metadata API coverage report will replace the existing static Unsupported Metadata Types page in Summer ‘18. The report shows the real time status of various metadata types and support in the API. It’s also part of a larger commitment from Salesforce to slowly increase Metadata API coverage over time. You can even upvote your favorite components through the UI so get your Selenium scripts ready (just kidding of course!). Though they did not provide dates and wrapped everything in a blanket of Forward Looking Statements, they did say that full Metadata API coverage was indeed a long term goal for Salesforce.
We’re thrilled about this announcement. It signals that Salesforce is listening to users and working to address the underlying issues that are hampering DX adoption.
DX’s new packaging requires breaking up your orgs into more modular pieces. To help teams do that more effectively, they announced the forthcoming Dependency API. With this new tool, developers will be able to get a better picture of how their metadata interacts with itself.
With this new API you can run simple queries that let you retrieve information about metadata dependencies. What fields are affected by this Apex class? And you can now see what custom fields or objects are referenced by a specific component. What Apex classes are affected by this field? The goal with this API is to help get a better sense of the structure of the org.
The Dependency API is a command line tool that will be available in pilot sometime in 2018. This again is a great tool for helping drive adoption of Salesforce DX and making it simpler to restructure your orgs for source driven development.
The Keynote then turned to developer productivity. A Heroku PM came on stage to talk about the Salesforce CLI. She made sure to emphasize that it is the Salesforce CLI. Not the Salesforce DX CLI. This was meant to remind us that the CLI is something everyone can use even if you have not yet adopted DX.
The most exciting announcement was that you can now build custom plugins to extend the Salesforce CLI and DX Core Library. Heroku built the Open CLI Framework (oclif) and open sourced it. Using this framework it’s now possible to create CLIs for everything in Salesforce.
We love CLIs at Blue Canvas, but we have also heard some push back from our customers about Salesforce’s movement towards such command line heavy interfaces. What happened to “Clicks Not Code?” has been a common refrain from our customers and partners. We’re curious to see what adoption of the Salesforce CLI looks like and how many users actually end up writing their own CLI plugins.
Apex Replay Debugger in VS Code
Newly appointed Salesforce product manager Andy Fawcett drew massive applause when he demoed the Apex Replay Debugger in VS Code which allowed users to get better real time information about their apps and how they are working. It’s available this summer and we’re excited about it.
We’re also generally excited about Salesforce’s new steps with VS Code.
Continuous Delivery & Beyond
To close the keynote Wade returned to the high level goal of Salesforce DX: to enable continuous delivery and continuous integration for Salesforce. This led to a nice demo of Heroku Pipelines and Heroku CI. The demo offered a glimpse of what a properly functioning DX implementation might look like. And it was very attractive. You had source control with GitHub to manage pull requests, rollback and merge conflicts. You had Heroku to trigger tests and manage migration of code. You had scratch orgs for creating rapid prototyping environments for previewing and testing.
It was an inspiring reminder of the promise of what Salesforce DX can be. Salesforce DX remains poised to be a disruptive tool for most teams developing Salesforce apps today. This kind of radical transformation is bound to have some growing pains, but the idea of being able to continuously deliver apps to end users is what will keep teams working at this.
Salesforce clearly sees that their next challenge is in helping teams cross the chasm to this new way of delivering software. Getting from A to B is proving difficult. But Salesforce is focused on the right areas with tools like the Dependency API and Metadata API docs.
Salesforce DX is about delivering features faster. It’s about increasing the quality of releases. And it’s about keeping developers productive. These are worthy goals and ones we share at Blue Canvas. They are worth the effort. We’re excited to work with DX to make this transition for people.