Making remote debugging easier to use - Key in the cognition
Feb. 9th, 2007
12:14 am - Making remote debugging easier to use
Shortly after joining VMware, I took on the challenge of making it easier for software developers to debug code running in a production environment where they don't have all the tools normally available to them during development. Traditionally, the only way to accomplish this has been through the use of remote debugging. However, while remote debugging can be extremely useful in certain situations, getting it to work is sufficiently cumbersome that it has remained the domain of the truly desperate. There are two parts to the process: running the code in debug mode on the production machine and then attaching a debugger on the development machine to the code running on the production machine. I realized that I could vastly improve the user experience if I could automate all this drudgery and present it to developers as a one-click action. But I knew that doing this would require a sequence of nontrivial actions:
- after building the code on the development machine, make the executable available on the production environment;
- execute the application inside the production environment so that it is prepared to accept a connection from a remote debugger;
- attach a debugger on the development machine to the application instance running in the production environment.
It didn't take long to realize that the first two steps would be fairly straightforward if the production environment was a virtual machine because then I could use Shared Folders to accomplish the first step and use our new automation API to accomplish the second. Fortunately, it is now possible to turn physical machines into virtual ones with minimal fuss.
Since nobody else had ever attempted to do something like this before, I decided to keep it simple at first to minimize the risk of failure. That meant choosing my battles carefully when tackling the third step. For the initial release, my target was limited to pure Java standalone applications developed using the Eclipse IDE, although it was to work on any combination of Windows and Linux as host and guest platforms.
I began by talking to a few Workstation customers who also use Eclipse for Java development so I could get a feel for their workflow and pain points. Then I sketched out the proposed workflow model for virtualization-assisted remote debugging and ran it by them along with rough mockups of my UI ideas. Based upon their feedback, I designed the feature as an Eclipse plugin that adds a new type of Launch Configuration to the stock set. The UI for this new launch config reuses most of the tabs already familiar to Eclipse users from running Java apps locally and adds a new one with a few virtualization options, of which only one requires the user to make a choice: in which VM should the code be executed? Once a launch configuration has been created and a VM selected, as with any other launch config, it can be activated in future simply by clicking on the Debug button in the Eclipse toolbar.
When activated, the plugin powers on the selected VM if necessary, shares the project folder containing the bytecode with the guest OS, finds an available dynamic port to use for remote debugging, looks for a JVM on the guest in the most likely locations until it find one, executes the application in debug mode and finally attaches the Eclipse visual debugger to the previously determined port on the VM. When the application is terminated, the plugin removes the shared folder so as not to leave a mess. For additional flexibility, developers also have the ability to do a few other potentially useful things:
- revert the VM to a snapshot before launching the application;
- share other folders during debugging;
- execute arbitrary scripts both before the application is executed or after it has terminated;
- once everything else has been completed, suspend the VM, revert it to a snapshot or power it off entirely.
Knowing that some Java developers would be using more complex runtime environments like application servers, I opportunistically threw them a bone as well. If they can get their application to run in debug mode and wait for a remote debugger to attach to it then I offer to them yet another type of Launch Configuration that greatly improves the user experience of attaching the Eclipse visual debugger to an arbitrary Java application running inside a VM. This one presents them with a nice list of instances of a particular Java application running on a particular VM so that they can pick the one they wish to debug instead of having to manually specify IP addresses and port numbers - the sort of details that made remote debugging a pain to use.
Keeping in mind that attention to detail means a lot when it comes to user experience, I added a few little niceties where possible. For instance, instead of always having to browse for the location of a VM, you can nearly always select it from a list of currently running and recently used VMs. And because most people won't care about sharing additional folders during debugging, I tucked the UI for that into a disclosure triangle. In keeping with the Eclipse tradition of always using a cancellable progress dialog for long-running operations, every step of the automated remote debugging process is accompanied by one of those. Finally, our Tech Pubs folk broke with their tradition of using PDF documentation to provide simple HTML user assistance that I integrated with the Eclipse Help system.
Anyway, that's enough from me! I want to hear what you have to say about this so grab a copy of the freshly minted Workstation 6.0 beta3 that includes the Eclipse plugin I made and take it for a spin.
Update: a least one developer is pretty excited about this.