As 2003 closed, the decision was made to transfer development of the Learning Management System to Dublin, Ireland. I was sad to be leaving a product I had done such good work on. But the new team in Ireland consisted of many of my former colleagues that I knew from when I worked there. It was great to work with them again, and to know the product was going into good hands.
In looking at several options, the best fit for my skills was to go back to my roots and work in the Notes group on testing tools. They had a number of tools to testing various aspects of the Notes platform. One, in particular, was critical to the process and was required to be run by every developer before they could check in any code. However, it was kind of cryptic to use and interpret the results. Also, although required to run it on their machine and one other operating system, a developer would typically be unable to find the hardware to do so.
Building on the web application development I had learned, I put together a prototype in my spare time that presented a web interface to the tool. You could browse to it from any machine, tell it the branch of source control that contained your changes, and request the tests you wished to be run. It would queue it up and execute them, leaving you to go about your business. When it was done the results would be e-mailed or a link IM'ed to you. Management was on the fence, fearing that developing the prototype into a deployable solution would be costly and take away from extending the coverage of the testing tool. However, the overwhelmingly enthusiastic reaction from the users was enough to allow them to let me work on it officially.
A client-server model was developed. The central server presented the web interface, which allowed you to register worker machines with it. These worker machines could be restricted to only being used by certain users or groups (to encourage departments to "donate" their hardware to the cause), or to certain times (to encourage developers to "donate" their machine while not in the office). The operating system of the machine was noted and it became a resource that tests could be run on.
The client side was deployed on each worker machine. It would validate its environment, and query the server for jobs to be done. Linking to source control, compiling Notes, building a server and launching test cases on it is not a simple operation. However lots of automation had been developed to do most of these tasks. The challenge in the client piece was to link these all together, and to handle the wide variety of error conditions that could turn up on each of the five platforms that were supported.
The end result was a turnkey solution. When a developer was ready with their fixes, they would browse to the tool, enter in their branch, select tests, and pick the operating systems they wanted it run on. It only took about two minutes to start it off, compared to 20 to 30 minutes per platform that was required earlier. Since the daily build criteria was that the same tests be run successfully when all the mergers were done each day, enabling all developers to test before submitting improved the entire process.
The base automation tool wrapped by this process has now been in use for over 10 years. It probably would have not made it to that milestone without the launch and maintenance system I built.