A new set of developer productivity tools from Salesforce is designed to help coders working remotely build applications more quickly and at scale.
On Tuesday, June 23, Salesforce announced a new suite of developer productivity tools designed particularly for coders who are working remotely — Code Builder, Salesforce Functions and DevOps Center. In the run up to the company’s TrailheaDX 2020 virtual event, I had a chance to speak with Ryan Schellack, Product Marketing Manager at Salesforce, about the new tools, how they can help developers streamline the app building process and when they will be available. The following is an edited transcript of the interview. You can listed to the interview on TechRepublic’s Dynamic Developer podcast.
Bill Detwiler: Ryan, thanks for joining us.
Ryan Schellack: Hey, Bill, thanks for joining. Thank you.
Bill Detwiler: All right. Thanks. Let’s start with the rundown of what the new tools are.
Ryan Schellack: Yeah, absolutely. So, Bill, we’ve obviously been working, just as everyone else has been, in a very interesting, fast-changing landscape. And something that we’ve been focused on actually for a while now, pre-pandemic and certainly now with this changing focus and scenario, is how to make people who build on the Salesforce platform more productive, more effective than ever before. And something that we want to think about is people are distributed now. I’m talking to you not from the floor of TrailheaDX in person, usually we’d be talking in San Francisco right about now, but instead we’re communicating over Zoom. That’s the standard for everyone.
So we’re introducing new developer productivity tools that are more relevant than ever for people that are needing to build and collaborate from anywhere. We’ve got three capabilities that we’re talking about now. The first is Code Builder. This is a brand new, web-based development environment that is optimized for Salesforce and actually powered by a partner. It’s powered by Microsoft’s Visual Studio Codespaces tool. We’ve worked with Microsoft to reimagine developer tooling for Salesforce, where we’ve been investing for years now on the desktop, now for the web. So people can build in their browser, which empowers them to build from anywhere, and to do so in a more collaborative fashion.
Something like 80% of Salesforce developers prefer to, or must due to IT regulations of their company, build with web tools. And so rather than build something bespoke, we’ve listened to our community. They love building on VS Code, which is Microsoft’s open source code of the dirt. They love the extensions we’ve built there, they’ve just expressed the desire to be able to use it from their browser. So Code Builder is designed to do that on top of Microsoft’s Visual Studio Codespaces.
So what we’re doing here is we’re providing people the ability to deploy a full-featured, fully-configured IDE right from their Salesforce at work. It runs in a cloud-hosted environment, you can access it from any browser, and that means that you can access anything that we’ve built over the past few years at Salesforce in terms of developer tooling, the CLI, those extensions I mentioned for VS Code, anything really we’ve innovated on right from your browser. It’s going to dramatically lower the barrier to entry for people that are developing on the platform because they don’t have to download software, install anything, configure it. They basically push a button and get a fully-feature development environment.
That also means that some of our low-code developers or people that are more declarative in terms of how they build, they’ll now have access to modern tooling right from their browser. They don’t need to worry about the scaries involved in configuring a typical desktop environment. That means everybody’s going to have access to more modern tooling, they’re going to be able to access it from wherever they go, and that’s going to make them more productive.
So that’s the first big thing that we’re announcing here. The other one is Salesforce Functions. This is a new way to build apps on Salesforce in a serverless, scalable way. We know that a lot of our developers have expressed a desire to tap into some of the benefits of Functions as a service. They’ve seen some of the vendors in public cloud do this, they’ve wanted to do it. And what we’re trying to provide here is more than just another serverless product, we’re delivering serverless agility with the Salesforce context. And so what that means is that you’re going to be able as a developer to write code, write some custom business logic, using languages that you might already be familiar with such as Apex, if you built on Salesforce, but also other languages such as Node.js and Java, and all of the open source libraries associated with them and build for Salesforce.
So you’re going to be able to write that code, and that code will deploy in response to events and data from Salesforce. You, as a developer, manage nothing else except your code. You don’t need to provision any infrastructure. You don’t need to manage any additional technology or overhead. You just write code, you give it to Salesforce, and Salesforce will run that code elastically on demand. That’s great because especially today, we’re in a very unpredictable circumstance, apps can be very dynamic, and capacity planning is another requirement that slows you down as a developer or a team from releasing new products and services.
So with Functions, you just focus as a developer on custom code, and your peers in the business, the business users, declared developers, admins, they can even invoke those functions via low-code tools that everybody knows and loves like Lightning Flow. They just go through a flow, they capture that function, they invoke whatever custom logic is in that function.
As a developer, I write the function for everyone. It can be reused, it can be used in multiple contexts. As a business user, I don’t need to care too much about the underlying custom code, I just benefit from that elastic scalability and that on-demand business logic to do something interesting, like create maybe a new PDF out of thin air. I don’t need to have someone build that PDF generation logic in Salesforce from scratch, if you will, I might have just one of my developers pull an open source library that someone else already built. And that means we can deliver a new service for our customers or employees even faster.
And speaking of delivering things faster, this third thing that we’re really excited about is DevOps Center. And so, DevOps, that’s been something that has been critical to our community for a while now. We’ve introduced a lot of capabilities over the past few years through what we call Salesforce DX, programmatic platform development tools for developers, but we know that a lot of admins, a lot of people who identify as Salesforce product managers, maybe they work in a Salesforce Center of Excellence at a company. They want to be involved in the release management cycle as well, and they want to use modern DevOps tools.
DevOps Center lowers the barrier to entry for them. Kind of like Code Builder, it’s making it easier for people that don’t necessarily identify as programmatic developers to leverage modern technology and capabilities to release and govern apps in a better way. So this means that you’ll be able to track changes across your orgs in a streamlined UI. You’ll have a new work object that you can use to kind of pin your changes against and collaborate with your team, so that you’re releasing your changes in a way that takes in user input, takes in feedback. And you’re going to be able to build more effectively than ever against source control.
So that’s like code and metadata in a repo like GitHub. Historically, you’ve kind of had to be a developer to take advantage of those really amazing technologies for collaboration and versioning. Now, it’s really easy. This DevOps Center provides that necessary abstraction layer, so now everybody can benefit from CI/CD modern automation practices that you see in DevOps, but without necessarily having to become a programmatic developer or be too familiar with those. So for developers, admins, everyone involved, this’ll mean faster releases and releases of higher quality.
Those are the three things that we’re delivering here that we think are going to be really impactful for developers, especially today in the current situation that we’re all working in.
Bill Detwiler: A lot of changes, updates were made to Lightning last year. I remember that was one of the things that we were talking about at TrailheaDX last year, and at Dreamforce. How do the new tools fit within the larger Lightning platform?
Ryan Schellack: Yeah, so these are all very much seamless with Lightning platform, and seamless with the changes that we’ve made over the past couple of years. I think last year when we talked, we were talking about open sourcing the Lightning Web Components’ programming model. Since then, we’ve done more open sourcing around our base components. Things like functions, for example, can be called, they can be invoked, not only from those declarative tools I mentioned like Flow, but from your Lightning Web Components.
So we keep thinking, how do we create more extensibility and a more seamless interaction of components across our entire set of developer capabilities? And so, that’s one example where you see that. Another example is that in terms of developing things like Lightning Web Components and developing for Lightening in general, in the past, the developer tools that we’ve had out of the box, for example, the Developer Console, which many developers know in Salesforce, they actually haven’t been equipped to build Lightning Web Components. You’ve had to use desktop tooling.
Code Builder allows you to use a web-based tool, but build modern Salesforce technologies like your Lightning Web Components or your Salesforce functions. So unifying the tool kit that you had for building on Salesforce and putting in the browser, that’s another part where you see the pieces of Lightning platform coming together. And then DevOps Center, of course, that’s an experience that you have within Lightning, so it’s using the Lightning user interface as a means to centralize artifact tracking and tracking of changes. For not just one org, but multiple orgs, so that everybody can have an eye on new feature requests, changes, whether they be for something that’s going to face a customer, such as a new community that you’re going to build with Lightning Community Builder, or it could be for something that’s an internal change, a new employee experience application.
All of these capabilities enrich the Lightening experience. They enrich the output that someone who builds on Lightning can deliver, but without them necessarily having to adopt a new way of building. We’re not making people go to another platform and then integrate in. All of these tools are natively integrated with Salesforce and with Lightning, and that means that you’ll be able to deploy them and adopt them much faster.
Bill Detwiler: In general, there’s always a tug between low code, no code, and building sophisticated tools that maybe developers need to write complex code when they need to do that. How does Salesforce balance that when looking at the new tools that it’s going to release? What’s your thinking about that in general going forward? What should we look for?
Ryan Schellack: Yeah, I think what you’ll start to see, Bill, is greater extensibility of low code to professional developer capabilities. In the past, this is a bit of a difference from how a lot of platforms, including Salesforce, have built in the past, which is they’ve tried to define these fine boxes, these clear boxes around where you as a developer can have access to tooling, et cetera. We think that our developer base is inclusive of low-code builders. We don’t think that they must have their own sort of boxed-in tooling. Instead, we think that low-code developers will see the capabilities that we’re building and immediately recognize value, and then be able to grasp that value.
For example, through these flows that you can now construct, which can develop or incorporate screens, which have Lightning Web Components fundamentally underpinning them, they can now reach out and through events, invoke functions. And as a low-code developer or a low-code builder, again, they don’t necessarily need to learn how to write a node function for any particular business reason, but they can better communicate to one of their peers who is a professional developer what they need and how the two of them can collaborate, and that collaboration process is much more seamless with more reusability.
And then especially for things like DevOps, DevOps is something where a lot of low-code users have communicated with us, “Let us in, we need to be involved in this. We know Salesforce, we know the org, but maybe we don’t know Travis or Jenkins or other CI/CD technology,” or they don’t really know GitHub that well. This makes it easier for them to participate, be a voice, be heard, and influence that release management process in a more impactful way. Not a way that works around the technology, but meets everyone where they are and helps connect them, so that no one as a professional developer is having to learn too much low code. If you’re low code, you don’t need to learn too much development capabilities.
In fact, with Code Builder, we’re going to introduce a SOQL Query Builder. All low-code builders need to build SOQL queries players at some point or another. We’ll let them do it from a modern user interface, but without having to really write any code. They’ll just use their clicks to actually build a full SOQL query, run it, test it, and then move it into their production org.
Release date and availability: Salesforce Code Builder, Salesforce Functions and DevOps Center
Bill Detwiler: Well, Ryan, it sounds really interesting. When do these official tools drop? When will they be available?
Ryan Schellack: Yeah, so I’ll go in order of the three of them. Code Builder is going to be announced at TDX in pilot, so we’re announcing it tomorrow I should say, on the 23rd. At TDX, we’ll be basically introducing it to the world in pilot. It will be a small, closed pilot. You can expect it to be an open beta later this fall, probably around Dreamforce time, and then early next year, it should be GA.
Salesforce Functions similarly is moving into a restricted pilot. Later this year around Dreamforce, same deal, we want it to be in a larger, more inclusive beta. And then early next year as well, that’ll be GA.
DevOps Center is on a slightly different release timeline. It’s another really interesting off-core innovation, so it’s something that we’re using a lot of new technologies to build, which means that probably late this summer, people will be able to get their hands on it in a developer preview instance. And then probably early next year, they’ll have a chance to get involved in a beta, and then shortly after that, it will be GA.
So a lot of these great things we’re announcing, developers will be able to get their hands on them very soon. We’ll have live demos for all of them at TDX, so definitely people should tune in. That’s our big developer gathering point of the year. And I think people will be really happy to see we’re not just talking about these things, but we’re showing them, and people can start to think about how they could use and benefit from them.