The Disco Blog Welcome Guest | Login or Register

On June 10th, I’ll be giving a hip tutorial on CI at the International Conference on Agile Processes and eXtreme Programming in Software Engineering.

The tutorial will walk students (with or without hangovers) through a series of exercises on a project where an automated build system is created that facilitates compilation, testing, inspection, and deployment. This copasetic build system will then be plugged into a CI server (Hudson in this case, baby) and students will code a series of features using Agile techniques like developer testing, which will ultimately demonstrate how a Continuous Integration process reduces risk and improves software quality. Students will then toast to CI over yet another pint of Guinness for lunch!

All you need for this tutorial is a laptop with Java installed (Java 1.5, please)– I will provide everything else (Hudson, Ant, required libraries, etc) expect beer.

If you are in Ireland (or just feel like going there) the week of June 9th (and you have a high tolerance for alcohol), then you’ll want to come to the International Conference on Agile Processes and eXtreme Programming in Software Engineering, baby! Drop me a line if you are attending (or are located in Ireland)– if you are up for a round of Guinness, even better!

Gant is a Groovy-based build system that uses Ant’s extensive collection of flower power tasks without all of the nasty XML– this enables you to leverage greater flexibly when it comes to hiply assembling software. Capitalizing on this flexibility within a CI process, however, can be somewhat challenging, unless, that is, you happen to be using Hudson, baby!

Hudson is an open source CI server that is particularly interesting given its ease of configuration and its compelling plug-ins, which provide increased visibility into such aspects as test result trends, for instance. What’s more, because it’s Hudson’s bag, baby, it has a copasetic Gant plug-in that enables you to easily employ Gant as a build process for any CI project.

Setting up the Gant plug-in is easy too– all it takes is 5 steps.

First, download the plug-in.

Next, you need to upload the smokin’ plug-in into Hudson– to do this, you need to go to your Hudson server’s home page and select the Manage Hudson link. This link is on the upper left corner of the page. Once you hit that link, you’ll be presented to with a list of options for managing Hudson. Select the Manage Plugins link, baby.

Once you’ve hit that link, you should see a small form that allows you to select the plug-in on your local machine and upload it. Do that!

So far, pretty easy, eh? Don’t worry, it doesn’t get any more difficult either– the next step is to globally configure the plug-in. This involves doing one thing– pointing Hudson to your installation of Gant, which if you’re following Gant’s instructions, is essentially is your Groovy installation. Therefore, go back to the Manage Hudson link and click the System Configuration link.

From there, find the Gant section. There are two form elements that require information– the name of your Gant instance and GROOVY_HOME (which is where you installed Groovy, man).

You’ll notice that you can multiple instances of Gant configured; hence, I usually make the name the version number of the underlying Gant instance in use.

Lastly, you’ve got to configure a particular job to use that version of Gant. During a job setup, you’ll note in the Build section, you can now select the Invoke Gant script checkbox. What a trip!

Once you select the checkbox, you’ll be presented with two form elements– which Gant version to use (this is drop down list with the various names from your global configuration) and which commands to invoke. By the way, you’ll note that the form says “Ant Version”– don’t be fooled though– simple typo, man. Once you are done configuring the job, don’t forget to hit the save button. I usually like to force a build to verify things are copasetic.

That’s it, baby! You are all done and ready to go with Gant and Hudson. Can you dig it?

If chewing the fat over TDD and arm wrestling over whose CI server is better happens to be your idea of a good time, then you, baby, are in luck!! This year’s copasetic North American Continuous Integration and Testing Conference is going to be in Denver on April 4th and 5th and promises to bring together a band of hip individuals focused on topics like:

• what is the one true language for testing?
• what does the future hold for build languages?
• is Disco the greatest musical genre ever to grace the airwaves?
• what does CI 2.0 look like?
• do the people who practice BDD actually make more money?
• will Jeffrey Frederick have long or short hair this time?

If an all out brawl over BDD versus TDD is your bag or a cage match between CI vendors is your idea of entertainment, then stop drooling and sign up today, man! I’ll see you there!

IBM developerWorks recently published a tutorial, written by yours truly, man, entitled “Spot defects early with Continuous Integration” — because it’s my bag, baby, this hip tutorial guides you step-by-step through the fundamental concepts of Continuous Integration using Hudson, Ant, and Subversion– when you’re done readin’, you’ll understand the copasetic benefits of Continuous Integration as well as how to set up and properly configure Hudson, Ant, and Subversion to work together. The resulting build process will run both tests and software inspections and will report back bogue violations almost as quickly as they occur, man.

If you are the slightest bit curious about Hudson, I recommend you read this tutorial as I go over just how easy it is to install, configure, and start disco dancin’ — what’s more, even though the tutorial assumes Ant and Subversion as the build tool and repository, you’ll see that you can easily plug in Gant or Maven, CVS or ClearCase, etc if that’s your bag. Dig it?

Jeffrey Fredrick of Agitar (and of course, CITCON and CruiseControl fame) and I will be hosting free webinar on how to implement a successful continuous integration and testing process. Jeffrey is a super hip guy and I’m really excited to have an opportunity to team up with him– if you’re curious about CI, developer testing, disco music, or are looking for something interesting to do for roughly 60 minutes, then join us!

Because it’s my bag, here are the details, man:

• When: November 14th, 9am PST (which is noon EST and 5pm in the UK, for those who are time zoned challenged, like myself)
• Where: Your desk, internet enabled refrigerator, or iPhone
• Why: Because it’s your bag, baby

Registration is required for this webex event.

The process of Continuous Integration (or CI, man) is about building software components often– in many instances, this means anytime code within a hip repository (such as Subversion, ClearCase, Perforce, etc) changes. The benefit of CI is simple: by building software often, issues can be found early as opposed to later in a software developmental life-cycle where issues (like defects) are more expensive to address. 


While CI is a process, the term often gets associated with a tool– but please keep in mind that CI is much more than a tool, man. In fact, the tool is probably the least important aspect of CI, because all the tool does it run your hip build (which, as you’ll find, is far more important) when a change is detected within a code repository.

Getting started in Continuous Integration then requires three things, baby:

1. An automated build process with a platform like Ant or Maven, for example
2. A code repository, like Subversion
3. A CI server such as Hudson, CruiseControl, LuntBuild, etc, although a cron job can suffice

As the process of Continuous Integration is about integrating software often, it stands to reason that the integration of software is fulfilled through the concept of a build. In the Java world, Ant stands as the ubiquitous build platform. With Ant, you can reliably perform (in an automated fashion) otherwise manual tasks like compilation, testing, and even more interesting things like software inspections and deployments. There are plenty of players in this space– Maven, Raven, etc so don’t get hung up on needing Ant, man. Once everything has been wired together though, your build strategy is by far the most important aspect of a successful CI process– without a solid build that does more than compilation, CI will wither in the absence of something interesting to do (almost like Rock music in the face of a Disco inferno).

Next, for CI to properly take shape, a repository for storing code (or SCM) must be in place to monitor. Essentially, a hip CI server polls a given SCM for changes; consequently, if any are found, the CI server will perform a checkout (or an update of a local sandbox) and execute a build (which is, more often than not, the same build developers can also execute in their local environment).

Lastly, for a copasetic CI process, it helps to have an actual automated process that monitors an SCM and runs builds when changes are detected. There are a host of CI servers available for the Java platform both open source and commercial– all are similar in their basic configuration, that is that they aim to monitor a particular SCM and run builds when changes are detected. They all differ with various bells and whistles; Hudson for example, is particularly interesting given its ease of configuration and its compelling plug-ins, which provide increased visibility into such aspects as test result trends, for instance.

The process of CI isn’t all that esoteric after all is it, man? Three simple things are needed and you are disco dancing– of course, as I’ve mused about before, CI is really about your build process. If that isn’t copasetic, spend time making builds a non-event and life will be trippin’. Dig it?

Because it’s his bag, a few weeks back Paul Duvall pointed out that “Continuous Integration is NOT about the CI server [man]” but about the process. I happen to agree with Paul, and in fact, as I like to point out (when given the opportunity) one of the most important aspects of hip CI process is the build itself. Think about it: if you take the bells and whistles out of a CI server, all you have is a sophisticated cron job that runs a build anytime an SCM changes.

With that painfully obvious fact looming, I’m still impressed with the number of people who get excited about neat-o CI servers without having examined what it is the CI server will actually execute when something changes. If your CI server is an automated compilation engine, that’s certainly a great start, but that’s not going to save your tail anytime soon, man.

To drive home this point, man, I like to demonstrate two scenarios when I give talks on CI. In scenario one, I execute a series of steps that show that life with CI isn’t any different for a developer than life without it (on the surface, that is). I:

• check out the latest version of a project in SVN
• add a feature
• write a test to verify that feature
• run a local build that compiles, tests, inspects, and even deploys
• execute an SCM update, if there is a change, I’d keep on truckin’ and run another build
• check the modified code in along with the corresponding test (assuming everything was kosher, baby)

So far, nothing new, right? These are the steps most developers take with or without CI in place. It is always fun to show the dashboard of my flavor-of-the-day CI server, which demonstrates it found the change and also ran a build without any errors. I then attempt to show how the process of Continuous Integration saves one’s tail by executing a few hurried steps. First, let me set the tone…

There is a problem in production; customers and management are in panic mode! We’ve got to figure out the problem ASAP or else!

With the ever so mellow ambience established, I:

• check out the latest smokin’ version of a project in SVN
• add a feature
• run a local build that compiles
• quickly check the modified code and prepare to split the joint (it’s Friday night baby)
• demand that my hip code be pushed into production as soon as possible

As you can probably see, in this case, I didn’t run a full build (which ostensibly includes tests); however, thankfully, the CI server then turns out to run a full build and, presto! — a test fails, causing a flurry of emails, IMs, etc to go out indicating there’s an issue. CI saved the day! Or did it?

As it turns out, in my case, it was the copasetic test that saved the day, man. All CI did for me was to execute it (via a build process that defined a test target) when there was a change– if there wasn’t a test that actually hit the modified code (and consequently failed), chances are that the offending code would have been pushed into production as soon as possible.

Continuous Integration is all about your build, man. Before you download that hip CI server, make sure you’ve got a solid build process that does more than just compilation– and as I’ve noted before, if you want to find issues quickly, start by writing some tests. Dig it?

Kohsuke Kawaguchi (the copasetic creator of Hudson) has created a hip Gant plugin for Hudson, which makes it amazingly simple to execute Gant builds within the context of a CI environment. If you haven’t tried out Hudson, you are in for a pleasant surprise– it is almost effortless to get up and running. Plus, now that you can integrate Gant without a smudge of elbow grease, I’d say Hudson is, well, um, groovy, man!

If you are in the Washington, D.C area and are looking for something to do on Thursday, June 28th, Stelligent is hosting a CI war stories discussion at our offices in Reston. There will be plenty of fine wine, but unfortunately, no disco music (and therefore, no disco dancing), but other than that, it promises to be a hip time. Plus, we’ll be raffling off a copasetically signed copy of Continuous Integration: Improving Software Quality and Reducing Risk.

If you ever wanted to chew the fat over a glass of wine with people obsessed with accelerating development, then you should stop by, man! See the post on testearly.com for more details.

The release of the hippest addition to Addison-Wesley’s Martin Fowler Signature series, Continuous Integration: Improving Software Quality and Reducing Risk, is just around the corner, man. Authored by Paul Duvall, with co-authors Stephen Matyas and yours truly, the book is currently available for pre-order and is scheduled to ship June 29, 2007.

Get your copy today, baby– it makes a copasetic Father’s Day gift as well as belated Mother’s Day, Secretary’s Day, Grandparent’s Day, Christmas, Chanukah, Kwanzaa, etc gift.