Salesforce teases developers with a trio of new tools ahead of TrailheaDX

Ahead of its TrailheaDX developer event this Thursday, Salesforce today announced a trio of capabilities and tools that aim to streamline processes for developers and provide new options as they build and deliver custom functionality on the Salesforce platform. The company also unveiled Einstein Recommendations for Trailhead, which uses AI to personalize the learning experience on Salesforce's self-service education platform.

The three developer tools are:

• Salesforce Functions — a set of serverless functions that developers can integrate with their data and events and run natively with elastic scale on the Salesforce Platform. Functions can be included in code built in open-source languages such as node.js and Java, in Salesforce's proprietary Apex programming language, or in low-code tools like Flow.
• Code Builder — a cloud-native, integrated development environment (IDE) powered by Microsoft’s Visual Studio Codespaces. Running directly within Salesforce, this browser-based tool allows developers to build apps fast from anywhere, with built-in features such as code completion, powerful debuggers and integrated source control.
• DevOps Center — an easy-to-use release management console that helps manage how apps progress through development from concept to launch on Salesforce. It brings admins and other declarative developers into DevOps processes, so that they can build against source control, collaborate more easily with programmatic developers, release apps faster, and do so using modern DevOps workflows including continuous integration and delivery (CI/CD).

Functions described as 'game changing'

This is a second coming for Functions, originally announced last year at Dreamforce under the Evergreen moniker. But the separate name has now been sidelined because it had led to confusion about whether or not the service was part of the core Salesforce platform, says Wade Wegner, SVP Product Management at Salesforce:

We wanted to be very clear this function is really meant to service and be part of the Customer 360 Platform ... It is not orthogonal. The word Evergreen insinuated it was some new kind of platform.

Functions is just part of the Salesforce Platform, full stop.

The ability to access Salesforce-native functionality in languages such as Java and Node.js was described by one developer last year as "game-changing." Wegner gave me an example of how much of a difference Functions makes to developers. One developer had an app where people were sending in emails with zipfile attachments, which the app then unzipped in order to read the contents. Before Functions, all this had to be coded in the Apex language, which doesn't include a library for unzipping files. This meant it was a very complex piece of coding that included various custom safeguards to make sure the operation stayed within Salesforce's governor limits. But with Salesforce Functions, the developer can now just pick a zip library in npm (Node package manager) and write one line of no-code to complete the same operation.

Functions, which is now available in developer preview and will likely go into open beta later this year, opens up a new wave of application building on the Sslesforce platform, says Wegner.

The function architecture enables not only synchronous and direct API communications but it really facilitates that event-driven architecture that is key for these next-gen apps that we're building on the platform.

Code Builder and DevOps Center

The introduction of Code Builder, now available in pilot, builds on work done by the vendor community several years ago to develop a standard called Language Server Protocol (LSP). This is a specification that allows programming languages to plug into the capabilities of developer tools without them having to be specifically coded into the tool. This means that, rather than the old Eclipse-based tooling of Force.com, Salesforce app developers can now have a full developer experience based Visual Studio Codespaces that is tailored to the Salesforce environment and delivered in a browser. The popularity of the Salesforce Developer Console demonstrates the clear demand among Salesforce developers for web-based tooling, says Wegner. Code Builder now provides that virtual workspace, on demand.

The final piece that brings the output of these various tools together as part of a managed DevOps pipeline is the DevOps Center, which will be available in development preview later this year. Wegner explains:

The DevOps Center is our acknowledgement that when teams are collaborating together, you need version control. Our developers want version control to make releases more agile and manageable.

The purpose of DevOps Center is to abstract away the complexity of DevOps control, so that administrators and low-code developers can become part of the managed process. Once a change is ready, the developer just makes it available for release in DevOps Center.

Behind the scenes we manage the complexity of doing a git add, git push, git pull request and so on. That developer doesn't lose out on the value of continuous development and can have tests happen when changes are made ...

DevOps Center will work with all of that. Connect your version control systems to the DevOps Center, we connect those things together.

My take

Earlier today I wrote about the launch of the MACH Alliance, a group of vendors promoting an architecture that is based on microservices and APIs, and is cloud-based and headless. What Salesforce has announced today isn't necessarily headless, but it's on-trend with the move to serverless architectures that combine the other three ingredients. Salesforce is moving with the times, ensuring that its platform can be part of the move to faster, more agile delivery of changing functionality in the modern enterprise.