In Progress: The Learning Curve We’re Still Climbing
Now that we’ve covered the high points of our Hudson build farm setup here at Sonatype, I want to discuss some of the current issues we’re facing at the moment. It’s important to realize that providing high-quality continuous integration is a long, involved process…not a quick, one-off event. Sure, you can get Hudson up and running fairly rapidly in a non-distributed environment. However, the path to distributed, multi-OS builds that capture a full range of testing can be very, very complex. In the end, if you can get by simply compensating for the problems I talked about in this series of posts, then you’re probably pretty lucky. Here at Sonatype, we’re certainly very conscious of the fact that our continuous integration setup could run more perfectly, and we continue to chip away at the list of things we’d like Hudson to verify automatically on our behalf. So, in the interests of full disclosure, I’m including a short wish list of items we’re currently working on.
I’ve been working on a Hudson-based build farm for Sonatype and Maven open source builds since sometime in September of 2008. I’ve learned a lot as a result, so I thought I’d share some experiences from the trenches. In this third – and probably, final – installment I’ll discuss some issues we tackled with our VMWare environment itself, and look ahead to some issues with which we still grapple on a day-to-day basis.
VMWare, Efficiency, and the Space-Time Continuum
Compared to what we went through trying to get Windows builds running reliably out on the build farm, this discussion is going to seem somewhat…nitpicky. However, there are some important things to understand when you’re running a build farm on VMWare ESXi, so let’s dive in and take a look.
I want to share with you what Sonatype is planning to do with Hudson – I hope you will be interested. We are planning a lot of work on the OSS side and will contribute that all back (provided the license of Hudson does not change to the CDDL). We are also planning to work on a commercially supported version of Hudson and we will create some additional commercial plugins. I think people here will be most interested in the OSS work so I’ll start there.
It all starts with the work we’ve done with Tom Huybrechts over the last few months to embed Plexus inside Hudson. This has several implications, especially for those who are interested in Maven integration. Tom made the PluginManager itself pluggable and the Plexus version of the PluginManager that was created finds Plexus components in its standard way. As a result plugins now work the same way in Hudson, Maven and Nexus.
The problem of eliminating clear text passwords from all media has a long history of failure and success. In the first years of the HTTP protocol, designers, despite existence of asymmetric encryption, decided not to use anything. Later, having been burned by cleartext passwords, they added base64 encoding. Which, as one may guess, did not fool anyone in the business of retrieving those passwords.
Luckily – Netscape introduced the SSL tunnel for HTTP, which was widely and enthusiastically accepted. This eliminated some of the threats, but had nothing to do with protecting the password storage. Most systems that interact with an authenticated service over HTTP still have to figure out a way to store these credentials. The alternative is for the serivce in question to use something like OAUTH or a distributed ticketing system (ala Facebook or Twitter). But, for most systems that need to interact with an authenticate service of HTTP this is a serious problem. If you need to deploy to an authenticated repository manager like Nexus, how do you avoid putting your password into your build?
I’ve been working on a Hudson-based build farm for Sonatype and Maven open source builds since sometime in September of 2008. I’ve learned a lot as a result, so I thought I’d share some experiences from the trenches. In this second installment I’ll discuss a few more details related to remote maintenance, along with the hurdles we encountered integrating Windows into our Hudson farm (and the solutions we found).
Eyes and Ears: Getting Access
Having access to the build farm is critical for maintenance, but it can also be very important to developers who are debugging a failing build. In our build farm, we’re using various mechanisms to provide this access, largely based on what is best suited for a particular VM operating system. The basic requirement here is to provide “natural” browsing capabilities for the filesystem on each VM, along with the ability to upload files if necessary (this came in very handy for installing and testing FlashPlayer, for instance).