It has been some time since we released the Apex Interactive Debugger. The feedback we’ve gotten on the tool has been largely positive! We want more of you to use the tool and have this positive experience, but not enough of you have had the opportunity. We are aiming to change that by giving this away to as many of you as we can.
If you are a customer with an Unlimited Edition org, you now have one session for the Apex debugger, for free, included with your org.
Some of you are now saying some (or all) of the following:
- “Wait, why not me?”
- “But I already had one, what now?”
- “Salesforce DX rules! What about scratch orgs?”
- “Great. How does this help ISVs?”
Allow me to address each of these.
To the people saying “YESSSSSSSS!”
I say “WooHoo! <high-five emoji>” That should pretty much cover this topic.
To the people saying, “wait, why not me?”
Let’s rewind. If you recall from my initial blog post on the debugger, we have some physical limitations to work around in providing the debugger. Specifically, each transaction holds on to a database connection until it’s completed, which effectively reduces the capacity of the pod. Too many connections held by debuggers means too little capacity, and one of the key rules we agreed to follow is that we would not impact non-debugging operations anywhere.
Due to the limited capacity, we wanted to ensure that debugging was being done primarily for your application development on the platform. We didn’t want people kicking the tires to crowd out mainline work; to ensure this, we put a pricetag on the debugger. That has done the intended job of upholding our agreement with our friends in operations. It has done so by limiting access too much. We’re working on changing that.
We now have a decent track record to look at in terms of debugger use. Before releasing this feature into the wild, we only had conjecture and mathematical modeling. We have also added a whole lot of new sandbox pods! Adding history of use – and thirty new sandbox pods – to the equation gives us the ability to reevaluate our scenarios. This has given us confidence that adding several thousand orgs to the mix would not cause us to go against our promise to stay out of the way.
We could not, however, calculate confidence that we could open this up to all developers.
Our goal still is to get this in everyone’s hands. Opening this up to the larger pool of Unlimited Edition orgs will give us even more data; that will allow us to recalculate the scenarios again. At that point, we hope we will be able to make this accessible to you, wherever you are. (I assume that, if you are still reading, you’re a legitimate developer on our platform!)
To the people saying, “but I already had one, what now?”
You just received an extra debugger session! You will get the one included in the Unlimited Edition license entitlement, which will be added to the one you had purchased. WooHoo! <high-five emoji> <disco dancer emoji>
To the people saying, “Salesforce DX rules! What about scratch orgs?”
Soon; very soon. Scratch orgs run on our sandbox hardware, so they’ll be debuggable. They are parented to the org that created them, so they’ll draw from the same pool of available sessions that sandboxes parented to that org draw from. In other words, they’ll be treated like a dev sandbox.
There is some work to do to make scratch org debugging a reality. We need to port the debugging functionality from Plug-in Classic to the new Force.com IDE. We need to do some server-side work to recognize scratch orgs like we do sandboxes. There’s some additional work around making sure you have all the source code locally, or dealing with it if you don’t. Once that is done, scratch orgs should be debuggable like sandbox orgs. (SAFE HARBOR WIZARD APPEARS AND SUMMONS THE FORWARD-LOOKING STATEMENT HOLOGRAM) Our current goal is to get this ready by the time Salesforce DX is generally available. Launching Salesforce DX is a huge project, so it’s possible that scratch org debugger doesn’t happen exactly then, but that is our current plan.
To the people saying, “Great. How does this help ISVs?”
Scratch orgs will replace the use of DE orgs in the ISV development lifecycle, which will give you the ability to use the debugger in your development environment. Developer Editions run on production pods, but our debugger does not. Because scratch orgs run on sandbox hardware, this will allow you to run the debugger in your scratch org development environments. This is getting us closer to our goal of making the debugger available to you, wherever you are.
We want you all to be able to efficiently write code that powers amazing applications built on our platform. The Apex Interactive Debugger is a tool that will make you more efficient as you author and maintain your code. We would like to provide this tool to everyone for free, and, if it ever becomes safe to do so, we’ll do it! For now, we’re providing the debugger tool to more people, and it’s still available for purchase for teams that want it.
About the author
Josh Kaplan is a product manager on the Salesforce programmatic platform. He knows many things about programmatic things, and about many other things, too.