Continuous Integration with Hudson

by on April 2, 2010 · 2 comments

Wow – a big, fancy phrase that may seem intimidating at first. Let’s break it down: “Continuous” meaning constantly, all the time; and “Integration” – building smaller parts into a larger whole. “Constantly Building” ? Well, that’s pretty darn close. So, what are we constantly building here? Sure, we’re churning out new features regularly, but I’m not talking about development. I’m referring to the automated building, deployment & testing of our website.

Testing

Despite what a lot of managers think about software development, it’s nothing like digging a ditch. Throwing more developers at a floundering project, or buggy system is like throwing a match on a pile of oil soaked rags. When the fumes clear, there’s not much left to clean-up. Enter software testing. It’s critical to get test harnesses built around every functionality our users interact with and we can do this in 2 ways. We currently employ unit testing and acceptance testing as part of the daily development process.

My wife distinguished these testing disciplines with a sewing analogy. Unit testing is like double checking your pattern while knitting a sweater. You need to be sure the knit stitch is correct while you’re doing it. Checking it once you’re done might be pretty depressing. Actually putting on the sweater is the acceptance test. Does it have two arms? A hole for your head? Does it fit? Applying these techniques to application code means unit testing individual methods to verify an expected output for a given input. An acceptance test is typically opening a browser, registering a new user and logging in.

Integration

The beauty of these tests is that they can be automated. That means after every application change (a commit to our code repository above), our Hudson Continuous Integration server automatically updates the test environment with the new application and runs all the tests we’ve written. If there are any problems (i.e. an error page in place of the “Welcome” page), all developers get an email notification that the build is broken. All work is immediately dropped, we figure out what went wrong, and then we fix it.

It also makes major application changes and new feature development a lot easier. As we have our tests in place, we are notified immediately if we’ve broken any existing functionality. In this way, we can be assured of giving the user the best browsing experience possible.

Did you enjoy this article? Get new articles for free by email:

Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>