Last night I went to the convenience store and they were selling brownies by the cash register. They were advertised as 75% organic, which made me wonder: what’s the other 25%? Pesticides?
Brownies
Reply
Monthly Archives: April 2007
Networking with Virtual PC 2007
I wrote a post last month about how impressed I was with Virtual PC 2007 and how it has changed the way I work. This is a follow-up about a networking problem that I didn’t discover until it was almost too late, as well as how to fix it.
I decided to install Vista Business on my laptop a few months ago, and aside from a few application compatibility issues, I’ve been pretty happy with it so far. One of the main problems is that Oracle 9i doesn’t work with Vista, and that’s a database we need to develop against. So, I fired up my Windows XP virtual machine, installed Oracle, and then connected to Oracle on the virtual machine just like I would if it were installed on another server. Everything was working smoothly… or so I thought.
A little background: The default networking option for your virtual PC is “Shared Networking.” This allows the virtual PC to share your host PC’s internet connection, but doesn’t allow the host PC to talk to the virtual PC. So, instead of using shared networking, I set the virtual machine to directly use my wireless network. Both the host PC and the virtual PC got separate IP addresses from the router, and could therefore talk to each other. The only thing I didn’t think about was that the second my laptop lost its connection to my router, I couldn’t communicate with the virtual PC.
So, there I was, minutes before a demo with an important client, and my application server couldn’t talk to my database, even though they were both on the same laptop.
The solution was relatively simple, but for some reason the information was really hard to find. First install Microsoft’s Loopback Adapter on the host PC, and then tell the virtual PC to use it for its network access. The process is explained very well here.
Version Labeling and Continuous Frustration
I approach continuous integration (CI) servers in the same way I do my IDE — as a tool of convenience for performing tasks I could choose to perform manually. I would no more have a build system reliant upon a specific CI server than I would write code that was only recognized by a specific IDE. Thankfully the CI servers with which I’ve worked conform to my philosophy. They do not seek to replace your build system as much as provide much needed automation. There is one area, though, where I feel CI servers violate this ideal, and that’s creating a unique build/version label.
Out-of-the-box, most CI servers provide a simple numbering scheme in order to produce a unique label for each build. Generating a build/version label is a task I prefer to happen within the build itself, so that the build is truly self-contained. Take our builds, for example. I’ve made use of the ant task buildnumber, so, upon a build, ant reads and increments a build-number property file and appends it to the project’s “base version,” the result being a label like “1.9.0.6″, where “6″ would be the build number. I imagine this is a common scenerio — indeed its why the <buildnumber> ant task exists. Once I launch an official build via command-line, label generation happens automatically, and the repository is tagged “Build 1.9.0.6″.
Introduce the CI server, though, and suddenly I’m having to jump through hoops to accommodate this setup. At the crux of the problem is this: from the CI server’s perspective, a build starts upon checkout or update of a project, and therefore wants to know the build label prior to actually running the build. That’s putting the cart before the horse, in my opinion, although I do understand the reasoning. Should access to the repository fail, for example, the CI server is able to report “1.9.0.6 Build failed due to VCS unavailability”.
What I’ve done is create a small script whose sole duty is to fetch the next build label for the CI server — fortunately the CI servers with which I’ve worked allow for pre-build script execution in some manner or another. With CruiseControl, I use an “antbootstrapper” to invoke a small ant build named “get-next-version.xml”. CruiseControl passes the value generated from that to the official build, so ant is invoked like so: “ant package -Dbuild.label=1.9.0.6″.
However, my work isn’t done. I still must ensure that my build-number property file is accurate, even if the build.label is being provided instead of being generated. So, in addition to configuring CruiseControl in the manner described, I also must have my build.xml extract the build number from the passed label (in this case, “6″), and update the build-number file appropriately.
Granted, I imagine most folks don’t rely on ant to generate build numbers, and therefore the CI server provided functionality is a convenient mechanism. The minority of us who do, though, ought to be able to supply build labels to the server in an easier fashion.