Rocket Surgery

I’ve done something simple, yet cool and useful in our Ant builds to make them work a little nicer with Hudson.  I’ve modified things so our Jars/Wars get stamped with version control information from Hudson.  To do this, I take advantage of the fact that when Hudson starts an Ant build, it puts certain key values in the environment variables, so I grab them and stuff them into the manifests for the jars.

Read the rest of this entry »

Will Gorman has a post here about adopting Hudson at his place of work…

As a contrast to my previous post regarding securing Subversion, I thought I would go through how to secure a Hudson installation using Active Directory for authentication and authorization.

Steps:

Read the rest of this entry »

I just got made a committer to the Hudson project.  Of course, it’s not like I’m a bigshot or anything, but still, you don’t get to do this every day, so I gotta take my bragging rights when they come…

In my last post I talked about getting involved with the Hudson project. In this post I will describe the steps I took to set up my build environment.

1. Get JDK 6.0 (Hudson cannot be built using 5.0 or earlier) and install it.
2. Get Subversion and install it.

Read the rest of this entry »

In an earlier post I wrote about my experiences trying to write a plugin for Hudson. In that article, I wrote about how I basically gave up because I was having too hard a time wrestling with Maven for the small amount of code I was writing.

Well, time passes, and I decided to try again, but this time I decided to look into what it would take to fix an issue I’ve had with Hudson. (For the curious: at the time of this writing, Hudson cannot verify that your LDAP settings are correct if your server does not allow anonymous binding - issue 1589).

Read the rest of this entry »

You know how there are “man crushes” and “girl crushes?”  I’ve got a serious code crush on Hudson.  My latest manifestation of this infatuation with this wonderful tool is that I have convinced my co-workers in a vastly C#/ASP.NET shop to stop using CruiseControl.net and Visual Source Safe and to switch to Hudson and Subversion.

This group used to have a huge, single, magic NAnt script that would check one of six projects out of VSS based on parameters sent in, build the project, and publish it to a development server.  Now, Hudson does the checkout from Subversion and the deployment, and the NAnt script just calls MSBuild or zips things up into deployable units.  Next we are going to hook in FXCop to do static code analysis on their stuff and have the problems reported and graphed using the violations plugin (which also reports our Checkstyle and PMD violations on the Java side), and show trends for their NUnit tests.

And the really nice thing is that everyone can use one dashboard to view both the Java and the .NET development efforts.  Great for transparency and accountability.

It’s fairly common to have your continuous integration tool running on the same machine that has your source code repository. It’s also fairly common to have your development server running on that same machine as well. But what if you don’t?

At my workplace we use Hudson for continuous integration (and anyone who’s read my blog knows I’m a big fan) and Subversion (which is also awesome) for source code management. These both run on the same machine. We also use JBoss as our web/app server, but on different machines, including the web server set up for development testing. We wanted to do automatic deployment to our development JBoss upon successful completion of a build.

Read the rest of this entry »

At my workplace we’ve started writing JUnit tests to monitor our systems and the systems of the other departements. One unit test pings all the servers we talk to or administer; one does an HTTP get from all the web servers we run, as well as the servers whose web services we call; another test does a quick query against all the databases we hit. We’ve set these JUnit tests up in Hudson to run every ten minutes; one failed test makes the project go unstable, and we get notifications by email and get on top of problems before the other departments notice it. They have their own monitoring software, which is pretty good, but we aren’t given access to it, and this way we get independent confirmation of what they are checking on.

We got this idea from something similar we did at a client of mine in a previous gig. To do cascading delete referential integrity, the DBA’s needed^* to use a delete trigger. Well, any time they made a change to the underlying table, they had to take the trigger off, make the change, then put the trigger back. Guess how often they remembered to put the trigger back. Anyway, we got so tired of them forgetting this and having to fix stuff all the time, that we wrote a unit test to make sure that deletes always cascaded like they were supposed to. Anytime they didn’t, we knew they dropped the trigger, and we got on the phone and fussed at them.

So, on the agenda for our suite are other neat things, such as connecting to our Dev, QA, and Prod databases, grabbing the metadata, and looking for subtle differences like missing indexes from one environment or another. We plan to make sure that the JBoss configuration files (such as connection pool definitions, system properties, JVM memory settings, etc) match what we have saved a copy of so we can tell if someone changes the server’s configuration without telling us about it. We’ll check Java versions, OS versions, etc. Anything that is external to our apps that can affect the success of those apps, we’ll make tests for it. We’ll have executable documentation of our assumptions.

After all, the real purpose of a JUnit test is to assert that something is true; and if it’s not, you’ve got a problem. Nothing says that what you assert to be true has to be the behavior of code — it could be almost anything.

^*I seriously doubt that they had to do it that way, but that was the way they insisted on doing it.

As I mentioned in an earlier post, I have been messing with developing a plugin for Hudson, which is in my opinion the best open-source continuous integration tool out there. It’s phenomenally easy to set up, it does most everything you need it to do right out of the box, and has a large number of plugins available to extend its function, such as support for Emma, Cobertura, PMD, Checkstyle, and even more unexpected things such as Nant and NUnit, Jira, even Ruby (which I’m sure my friend Mike just loves).

But it doesn’t have something I would like to see. I’d like to be able to define (in my job config) a descriptive name and location in the workspace of specific artifacts generated during my build - a sort of “General Publisher”. For example, if my build generates a test PDF, I would like to have a link titled “Test PDF” show up in the central part of the build results page similar to the “Test Results” link, or to the left like the console output links. Same for if my build generates numerous HTML files (there have been numerous times when I needed to do XSL transforms off of source XML files to make a documentation mini-site similar to Javadoc).

Now, of course there is a way to do something kinda close already. You can tell Hudson to keep the desired files in the “Archive the Artifacts” box under “Post-build Actions” and it will make a link for your artifacts on the page. But there’s a couple ways in which this falls short. One is that you don’t get a descriptive name for what you’re archiving and what Hudson displays. A second is that if you want to display a generated multi-page site you need to put the name of the base directory in the “Archive the Artifacts” box — and when Hudson sees multiple artifacts in the list, you basically just get a clickable directory listing of the archived files, from which you need to pick out “index.htm” or whatever to really view the web pages.

So I decided to try writing a plugin to do what I wanted.
Read the rest of this entry »