Ananya Jha is a Product Manager working on the IDE experience here at Salesforce. This means she gets to dive into all the cool new features that Salesforce releases in its extensions and eventually serves you through VSCode and Code Builder.
In this episode, we talk about the current state of Code Builder, the Salesforce IDE, and some of its great tools that can benefit you. We also discuss the advantages of using a repository as a source of truth when using Code Builder or Salesforce IDE, PMD’s relationship with IDE, and the Apex Replay Debugger.
Show Highlights:
- The core desktop experience with Salesforce IDE
- What the Code Builder technology looks like and how it can be accessed today
- Other tools inside the IDE Ananya recommends for people to track conflicts and changes
- Ananya’s favorite extensions and tools
- Query Builder and how it works within the IDE
- How the Apex Replay Debugger Works
Episode Transcript
Ananya Jha:
Yeah, I went to college for business. I had grown up with my dad telling me that you should really think about trying computer science. I feel like you might like that.” I always was like, “No, because that feels super painful and you’re telling me to do it, dad.”
Josh Birk:
That is Ananya Jha, product manager here at Salesforce. I’m Josh Burke, your host for the Salesforce Developer Podcast and here on the podcast you’ll hear stories and insights from developers, for developers. Today, we sit down and talk with Ananya about the current state of Code Builder and the Salesforce IDE and some of the great tools within it that you will want to know about but we are going to start with her earlier picking up where we left off with that cold quote. Right?
Ananya Jha:
But at some point during college, ended up trying some CS classes on the side and thought it was super cool and then got lucky enough that I ended up talking to Salesforce at some career fair and ended up interning as an engineer.
Josh Birk:
Nice.
Ananya Jha:
I was like, Okay. This is actually cool.” I don’t know if I ever thought I was going to stay an engineer forever but it definitely was super interesting.
Josh Birk:
And I got to give a call-out here. While you were an intern, it sounded like you had some pretty interesting projects, but I want to ask after a microservice to modularize sandbox creation algorithm by using Docker and Kubernetes and what’s that?
Ananya Jha:
Oh man, that was a long time ago. That was a real interesting project but yeah, it was really interesting because even when I interned, I was lucky enough that I interned in developer experience. I was the sandbox team and worked with Rohit, who was our PM back then too. But yeah, back then, microservices were the hot new thing at Salesforce so I was doing a bunch of research into trying to see could we convert what we were trying to do with some of our sandbox routing into more of a microservice type of an architecture.
Josh Birk:
Interesting.
Ananya Jha:
Yeah, I learned a lot about Kubernetes that summer. I don’t know how much of that has stayed. Yeah.
Josh Birk:
I feel like a lot of people have that Kubernetes story in their background-
Ananya Jha:
Exactly.
Josh Birk:
… so early like, “This is going to rule the world,” and now we’re five years later. Yeah. How would you describe your current job at Salesforce?
Ananya Jha:
Yeah, now at Salesforce I’ve moved over to product management. I’m now doing some product management for our IDE experience. I now get to look into all of the cool new features that we’re putting out via our Salesforce extensions and then eventually serving to y’all through VS Code and Code Builder.
Josh Birk:
Nice. Now, when we say the Salesforce IDE, and we’re talking about VS Code, what does that package look like? What’s the core desktop experience?
Ananya Jha:
Yeah, that’s a really good question and I’ll actually maybe elaborate on something else because this has often been confusing for people. When we talk about the Salesforce IDEs, what is that really? For most folks, they’re used to either your desktop experience where you have VS Code right now. And for VS Code, if you’re a desktop user, usually your journey is going to look like something where you install Visual Studio Code to your desktop and then you go in and you install your Salesforce CLI and you install your Salesforce extensions to VS Code. Now, all of that is one option for your Salesforce IDE.
Josh Birk:
Correct.
Ananya Jha:
For our non-desktop users, so far we’ve given you the option of developer console. Code Builder is the next step forward so that you don’t have to keep using developer console but the great thing about Builder is that again, we want to give you that same Salesforce IDE experience.
Josh Birk:
Gotcha.
Ananya Jha:
Inside of Code Builder, you’ve already got your Salesforce extensions and you’ve already got your Salesforce CLI. Once you’re in that environment, it’ll look and feel the exact same as your desktop experience but as a whole, you basically have two options for your Salesforce IDEs.
Josh Birk:
Okay, a couple things there. Just to level set for old school people like myself who might be veterans of the browser wars and have opinions about Microsoft and whatnot, Visual Studio Code distinct from Visual Studio, Visual Studio Code is free. It’s open source, I believe. Is that right?
Ananya Jha:
Yeah, it’s free and open source, which is really cool.
Josh Birk:
Yeah. Now when it comes to Code Builder, what’s that technology look like? Am I looking at a browser emulation of what VS Code is doing or how close is it to the desktop IDE?
Ananya Jha:
It’s built on top of the open source version of VS Code so Code OSS, I believe, but it’s hosted on top of AWS. It’s not quite exactly VS Code Code Spaces as you might see out in the wild, but it is going to feel and look the exact same as the native VS Code experience.
Josh Birk:
What you see in one, you’re basically seeing the exact same thing in the other?
Ananya Jha:
Exactly, yeah.
Josh Birk:
And how can people access Code Builder today?
Ananya Jha:
That’s a good question. Code Builder is currently in open beta, so folks can go ahead into app exchange and then actually go and install it as a managed package.
Josh Birk:
Gotcha. And when we say open beta, I’m looking at my list of Salesforce pilots and betas and that basically means you can kick the tires. You can use in a sandbox. You can use in a developer addition, but we don’t intend use this production. Is it that style of beta or is there a different beta?
Ananya Jha:
It’s exactly that style of beta.
Josh Birk:
Got it. Nice. Let’s talk a little bit of best practices and feel free to be as wildly opinionated about this as possible. What are some advantages to using a repository as a source of truth when you’re using either Code Builder or the Salesforce IDE?
Ananya Jha:
Yeah, one thing that we’ve often heard folks run into in the past is where you are maybe not necessarily using a repository as a source of truth and instead, you end up in this situation where maybe you and other folks on your team are just overwriting changes on top of each other because you’re all developing in the same organization. You’re pushing and you’re deploying to that same space. And so, you run into these situations where maybe somebody on your team has made some changes and you’d pulled down something a few days ago and started working off of that branch or that version of your org and you go and now you deploy and you overwrite the other person’s changes.
Those are the types of things that we’ve often see people run into when they’re not using version control. Using version control is great because it basically lets you divide up all of your different environments. If you’re currently in a place where you’re just working on developer work, you’re going to have your own dev branch that you can keep all of your changes localized to and it helps really modularize those changes and makes sure that you’re not inadvertently affecting somebody else’s work and helps keep that one, clear source of truth on what exactly is that representation of your org right now.
Josh Birk:
And putting on my good Salesforce hat, give a shout-out to DevOps Center, which is obviously also designed to help mitigate these changes in conflicts. Are there any other tools inside the IDE you recommend for people to track conflicts and changes and dips in the org?
Ananya Jha:
Yeah, definitely. Completely agree with you. DevOps Center is going to be a game changer for that. Inside of the IDE right now, you have a few options. If you really just want to understand what the differences are between your local project and what you’ve got inside of your org, you can do something called running your diff command. If you right click on any of your files, you should see the option to run a diff of this file against your organization and then you’ll be able to see a nice little view of, “Hey, these are all your local changes,” in the left-hand side, and then you’ve got what exists in your org on the right-hand side. You always have that as an option within the IDE.
The other way that we’ve really tried to help folks who want to bake this really more into their development process is giving them the ability to detect conflicts. You have this option where inside of your settings in VS Code you can allow for a detect conflict on deploy. And so every time that a deploy happens, we’re actually going and making sure that you’re not overwriting changes that might have occurred in your org since the last time that you ran a retrieve. I think that’s been really helpful for folks to make sure that they’re not just accidentally overriding changes that they didn’t even know were there in the org previously.
Josh Birk:
Right-
Ananya Jha:
Yeah, and then-
Josh Birk:
You’re on a dev branch. I’m on a dev branch. We didn’t realize we were actually working on the same component and now we know not to write over each other’s code.
Ananya Jha:
Yeah, exactly. And then the other cool thing I think about using VS Code is the fact that they’ve got some really nifty baked in version control tooling too. If you are using GitHub, then VS Code itself has a super helpful little branch icon in its left sidebar and you can click that and that’ll also just let you see visually all of the recent changes that you have to any files and it also lets you have that basic, “Push this to my branch,” and those types of interactions too. If you are using version control, I think you’ve got some pretty cool features to help you out with that baked in as well.
Josh Birk:
Nice. And just to reiterate, we have feature parody here when we’re talking about the IDE and Code Builder. Everything’s the same.
Ananya Jha:
Exactly, yep.
Josh Birk:
We have a lot of different extensions and tools that we can work with the Salesforce IDE. Do you have a couple of favorites?
Ananya Jha:
Yeah, I think obviously the ones that are in inside every extension pack I am very partial to, but of course, there’s a ton of really awesome community contributed extensions that folks have created too that I know have been really, really helpful for people for… Okay, the one that I’m going to talk about today is this one that’s called the SFDX-Hardis, I think, is what it’s known as. But this extension is really cool because it helps you visualize which org you’re working inside of.
It does a ton of other things, but what I find it most helpful for is that when you are working inside of an org, sometimes I’m not changing the VS Code window that I’m in and there’s no easy way for you, at a glance, to detect which org you’re currently inside of without going and checking to see in your org picker, “Hey, this is the exact org that I’m in.” And so with this extension, it’s actually going in. It’s completely changing the color of your VS Code background and everything so that you have a nice, bright visual indicator letting you know that, “Hey, right now you’re in your pod environment.” I’d hope not, but maybe.
Josh Birk:
Right. That one’s the bright red background, I would hope.
Ananya Jha:
Yeah, exactly. But yeah, I think this one’s been really cool. It’s been a really awesome one for folks to be able to manage all of the different authorizations that they might be working against.
Josh Birk:
Very cool, and we can get a link to that in the show notes.
Ananya Jha:
Definitely.
Josh Birk:
Is there anything distinct in Code Builder based on the fact that it’s within an org? Does it jump to knowing what its org shape is or anything like that?
Ananya Jha:
I think what’s interesting about Code Builder is that you are launching it directly from your org, but once you’re inside of Code Builder, you again, are going to be in the same type of environment that you are when you’re inside of VS Code. You still have the ability to go in and now actually authorize against whatever specific org you wanted to work against.
Josh Birk:
Got it.
Ananya Jha:
Yeah, once you’ve gone ahead and done that authorization, then you’ve got all of the basic knowledge about your org shape that helps you inside of your normal VS Code experience as well.
Josh Birk:
Got it. Tell me a little bit, and fans of the show know I’m a big fan of this project, tell me a little bit about P&D and how it works with inside the IDE.
Ananya Jha:
Yeah, P&D I think is really cool because it helps you catch a lot of those issues that you might want to collect early on in your process from right there inside of your IDE. With Apex P&D, we currently have it packaged inside of your Salesforce extension pack and it helps you with all your basic static analysis. It’s going to allow you to locate all of those Salesforce best practices, catch any stylistic errors, make sure that you’re using all the corrupt constructs that you’d like folks to be using and all of that is right now accessible to you within the IDE.
Now something cool that I can share about this too is that later this year, we’re actually looking at bringing Salesforce Code Analyzer to the IDE as well. All of that detection that you might be doing as part of your CICD processes, you can also now shift that a little bit further left in your development lifecycle and do it from your IDE. You can imagine you’ll be able to find things like security vulnerabilities and later on, even take advantage of their new graph engine analysis that they’ve brought out too.
Josh Birk:
Nice. Wow, that’s awesome. And if anybody’s listening and curious about the distinction between Code Analyzer and P&D, point you back to a couple weeks ago. We had Roopa Mohan talking about exactly that. Okay, talking about another Salesforce specific tool, what is Query Builder and how does that work within the IDE?
Ananya Jha:
Yeah, SOQL Query Builder is another one of our extensions that we’ve put out. It’s really cool because I think it’s our first step towards reaching future parody with developer console in terms of doing your software queries. Right now, it’s something that you can access from right there inside of your IDE. It’s part of your extension pack. You’re essentially just going to go ahead and toggle SOQL Query builder on from inside of your IDE using the command palette. And then from there, it already has knowledge of the custom objects and all the metadata that you would have in your organization so you now have this nice point and click interface for you to build those SOQL queries that you’d like to be working with.
Josh Birk:
Got it. And as somebody who’s often had to reference three docs in order to figure out exactly what the right format for a complicated SOQL query is, I’m assuming this helps sorts that out because it’s like Mad Libs create your query.
Ananya Jha:
Yeah, exactly. You have this really nifty UI that you can use and it’s basically going to show you like, “Hey, now you have a dropdown. You don’t need to remember where you’re trying to pull your data from. You can just scroll through this list and easily select the different fields that you’re trying to work with.” I think it just makes the whole process so much easier because otherwise, sometimes you start writing a SOQL query and you’re like, “I don’t know exactly what field I needed to access but I feel like I know the general syntax.” I think this really just helps you visualize all of that without needing to keep all that inside your head.
Josh Birk:
Got it. I love it. Now I feel like in the long history of Salesforce tooling, we could do almost a whole episode on the history of us trying to solve this problem, and the problem being developers are used to a Visual Studio experience where everything’s running locally and if they want to put a break point in the middle of a function and say, “Hey, what’s the variables? What’s going on here? Let me see what’s happening before it breaks.” We’ve been trying to solve that in the cloud and I think we’ve had four or five different iterations of it at some point. How does Apex Replay Debugger work and how does it compare to that tooling these days?
Ananya Jha:
Yeah, so Apex Replay Debugger, I think, has gone through a ton of iterations over the few years like you’re saying. In its early days, I mean, the basic gist of how your Replay Debugger works is that you’re first going in and you’re turning on your trace flag. We’re actually now going to start listening for logs being for any events occurring within your organization and then we’ll start tracking all of that info inside of debug logs. That’s our way first to just start generating debug logs based off of whatever interactions you’re currently doing. Once those debug logs are generated, we then have to go pull that information down to your IDE and then we start stepping through the debug logs themselves to simulate that live debugging experience that you would expect otherwise.
And so, what’s been interesting is that over the years, we’ve really tried to make that process be simpler for users because you can imagine, I just listed out four or five steps. You have to know that you got to turn on your trace flags. You then have to go and maybe update your checkpoints if you added in some new checkpoints. There’s a lot that’s going on in the background and so I think a year ago or so, we put out the first of a few changes to create an easy replay debugging experience. And so with that, what you can do is you just have to click one button either from inside of the file that you’re creating your apex test in or from your apex test sidebar, and it’ll immediately just launch you into that first step of your debugger. Behind the scenes it goes and it runs the test for you. It collects that debug log, pulls the debug log down, starts the debugger, and inserts you in the first line of your program execution.
Josh Birk:
Got it.
Ananya Jha:
It’s really just trying to take away all of that extra work that you would have to do otherwise.
Josh Birk:
Nice. Nice. And speaking of behind the scenes, tell me a little bit about how the Apex and Lightning Language servers work and is it something that’s just a hero behind the scenes or is it something that developers need to interact with?
Ananya Jha:
Yeah, that’s a good question. I think for the Apex and Lightning Language servers for most developers who are using our tools, you shouldn’t have to go in and mess with any of that. Ideally, we’re staying on top of things and you’re able to just take advantage of all the features that we put out through it. But what’s cool is that the Apex and LWC Language servers, the main purposes of them is to provide you with all of those typical IDE features that you would expect from any other industry standard IDE. It allows you to do things like code completion, go-to definition, find all reference, auto complete, and all of that.
Every so often, we have heard from folks that’ll see that maybe valid syntax that has come out recently in Apex is being marked as invalid according to their IDE. That usually happens because we need to go behind the scenes and then up regenerate the version of Apex that we’re working with and update all of those files. And so, this is actually an active issue that I have asking about and our is, super exciting, I think actually going to be putting out something later this week to help alleviate all the new Apex system references.
Josh Birk:
Very nice. Very nice. Well, speaking of things coming down in the future, anything on the roadmap that you want to give a shout-out to?
Ananya Jha:
Yeah, one thing that we’ve had folks asking about in the past a ton has been around, “How do I really interact with my metadata when I’m in my local environment,” because for a lot of people, if they’re industry developers who are very used to having to retrieve files from either their source control, just the concept of pulling info down locally is a familiar paradigm. But for a lot of folks, it can be like, “Hey, I’m inside of this environment. Salesforce is somewhere else. How is my metadata supposed to get here?”
And what we’d created a few years ago to help make that visualization easier for folks is the org browser. With the org browser, you can actually view all the different metadata types that exist, and then you can see which components you actually have within your org and got it. You can see everything that exists within your org and then select things that you would want to retrieve and pull down locally. Now, unfortunately, the org browser had only been exposed to non-source tracked orgs. If you were in a sandbox, you could use it, but if you were in a scratch org or a source tracked sandbox-
Josh Birk:
Got it.
Ananya Jha:
… you did not have any access to it. And so, the most recent development is that in the next few weeks, we’re actually going to be exposing the org browser to source track orgs. Now folks inside of scratch orgs and source track sandboxes will actually be able to use the org browser and view all their metadata components and have a nice UI friendly way of completing that interaction.
Josh Birk:
Got it. Nice. Anything else or do you have that one user feature that you’re like, “Gosh darn it, I just really want to get that one tackled?”
Ananya Jha:
Yeah, one of the other things that, and this is actually still in the same area, but the other thing that comes along with this helps us also get closer to where the Salesforce CLI is right now. But we’re also working to expose, deploy and retrieve for source track orgs. That is cool because in the past, you’ve been in this place where you need actually push all of the changes that you might have locally in your project, even if you’re not necessarily trying to get all those things out there. Now you have the ability to complete these granular operations of deploying and retrieving and it just makes it a lot easier, I think, for you to complete little bits of work and just test that instead of having to batch all of your changes together.
Josh Birk:
Very cool. What’s the best resource you recommend for people to get a little bit of a mastery of this? Is there stuff on Trailhead up on developer.salesforce.com? What resources would you point to?
Ananya Jha:
Yeah, there is a ton on to Trailhead that I think is really helpful, specifically around development models, and I feel like those Trailheads also always give you a good job of just explaining how you should work with source control and integrate that into your development life cycle. And then on our developer docs for the extensions or for the Salesforce IDEs, we are actually working on adding in some more information on that too for how you can best complete all of these metadata operations. All of that is soon to come on our Salesforce extension stocks as well.
Josh Birk:
And of course, talking about roadmap and things that everybody was talking about these days, how do you think generative AI or GPT might affect the developer experience with the IDE down the road?
Ananya Jha:
Yeah, that is a really good question. I think the biggest trends that we’ve seen impacting the developer experience, especially inside of IDEs has been generative AI. We’ve seen a lot of cool things come out from GitHub, of course, in terms of co-pilot and all those other options and I think those are really good examples of how you can see AI impacting your developer experience and at the end, really just helping improve your productivity. And so we at Salesforce, are really looking to have that same impact on folks’ developer productivity and overall make it easier for developers to get started with Salesforce development from within their IDEs. Later this year, we are going to be looking at putting out some AI enabled features to your IDE experience as part of our Einstein GPT for developers product.
Josh Birk:
Got it.
Ananya Jha:
And so right now, we’re mainly going to be focused on Apex cogeneration to start with and it’s going be focused on, again, that code generation experience within your IDE. How can we make it easier for you as you are doing your development to just immediately have your development experience be supercharged? And we’re really looking to do that by allowing you to see some AI generated code as you type, maybe based off of some natural language queries that you ask Einstein GPT. But overall, what we’re looking to do is really help improve developer productivity and make it easier for folks to get started with their development experience by giving you some more of these features within the IDE. We’ll have a lot more details and a lot more tell you later on this year.
Josh Birk:
I assume we’ll probably have a lot more questions, so we’ll probably have to get you back on the show.
Ananya Jha:
Yeah, for sure.
Josh Birk:
And that’s our show. Now before we go, I did ask Ananya’s favorite non-technical hobby and well, it’s something that she put some steps into.
Ananya Jha:
Oh, that’s a good question. Let’s see. I really like dancing actually.
Josh Birk:
Nice.
Ananya Jha:
Yeah, I dance a ton outside of work, so you can always catch me in some Bollywood fusion class.
Josh Birk:
I want to thank Ananya for the great conversation information and as always, I want to thank you for listening. Now, if you want to learn more about this topic, head on over to the show notes for this episode. If you want to learn more about the pod in general, head on over to developer.salesforce.com/podcast where you can hear old episodes, see the show notes, and add links to your favorite podcast service. Thanks again, everybody. I’ll talk to you next week.