Consultant Eric Minick says that CI should be focused on testing, not on builds.

He makes the following interesting points:

• automated tests verify successful integration, not the compilation/build process
• running a build multiple times with different test “suites” is complicated and error prone
• performing many different kinds of builds in an enterprise environment is wasteful and much of the testing is outside of source control

His recommendation is that a given software “build” (a set of packaged software bits that represent the output of the compile/generation process) should be passed through multiple testing stages over time. Personally, I visualize this like a car going through a car wash - we don’t build a new car for each brush and spray hose - we use the same car over time.

My take: I think, conceptually, that there’s a lot of merit here - because if you have an active project with a lot of commits, and you’re firing off all sorts of different builds with different test profiles, you are dealing with a constantly changing code-base as you run different types of tests. In other words - the code that you run the “database” integration tests on might be subtly different from the code you run the “web services” integration tests on.

And that’s a fair point - there are situations where you end up with a bug that “slides between” two types of builds. Eric’s solution certainly addresses that issue, in a reasonably elegant way.

However:
A) those issues don’t happen that often, in my experience (if they happen all the time to you, then definitely consider Eric’s idea)
B) Most sites I know of have at least one “Mother of all Test Suites” to cover and catch bugs that slip past the “lesser” test suites.
c) The amount of “waste” involved in fairly meaningless

I applaud UrbanCode’s innovative thinking. If this is something that speaks to you, by all means, give it a try. But don’t trash your existing build model just yet.

Hudson is an open source CI server that is by far the easiest one to configure. Second to ease of use is Hudson’s impressive plug-in framework, which makes it easy to add features. For instance, Hudson has a plug-in for tracking FindBugs issues, PMD issues, and CheckStyle issues over time as well as code coverage. It also trends test results from JUnit, as well as build results and corresponding execution times. In spite of all these cool features, we had to find ways to get around some common issues we faced at work using Hudson.

This article describes a few real-life tips and tricks that we have found at work and will assist in configuring Hudson to work most effectively in your environment as well:

1. Changing Hudson home directory
2. OutOfMemoryError
3. Securing Hudson
4. Hudson Views
5. Hudson and Groovy
6. Spaces in directory names
7. Browser to use

Changing Hudson home directory:
Hudson by default uses the $USER/.hudson directory as its home directory. If you want to change the home directory, set the HUDSON_HOME environment variable to some other location before startup. This is where Hudson maintains its configuration files and manages its jobs. If you are using a batch script to run Hudson, you can set the HUDSON_HOME there as well:

set HUDSON_HOME=c:\hudson\ci_jobs

OutOfMemoryError:
If you are seeing this error, set the maximum heap size as such:
java -Xmx512m -jar hudson.war If you are seeing the same error in spite of increasing the memory, report the issue to Hudson mailing list and take a look at the following link:
http://hudson.gotdns.com/wiki/display/HUDSON/I’m+getting+OutOfMemoryError

Securing Hudson:
Hudson does not perform any security check in its default mode. This means any person accessing the website can configure Hudson and jobs, and perform builds, and download all the files from within the workspace. Hudson can be configured to authenticate users and enforce access control. In the “Matrix-based security”, you can basically configure which users have what permissions in a big table. From the Hudson dashboard, click on Manage Hudson link on the left hand side which will take you to a page as shown below:

It is also a good idea to secure the Workspace as shown above. If not, once you have a successful build, anyone can download the source code from the Hudson Dashboard as such:

Hudson Views:
Rather than having a long list of all the Jobs, organize your jobs into different views; like Commit Builds, Nightly Builds and so on.

Hudson and Groovy:

The Groovy plug-in which can be found here is very useful. In our case, we are using it for many purposes. To name a few:
1. To unlock all the files which are locked by the SCM. Download a free utility called unlocker.exe and run the groovy script to unlock files as such:

new File("directory where files are getting locked").eachFileRecurse{file ->
def command = """"C:\\Program Files\\Unlocker\\Unlocker.exe" ${file} -s"""
def proc = command.execute()
proc.waitFor()
}

2. And also to change the file permissions on directories.

def ant = new AntBuilder()
ant.chmod(dir:"directory which needs the permission to be changed", perm:"ugo+rw", includes:"**/*.*")
println "changed permissions on dirs"

Troubleshoot Hudson:

If you want to troubleshoot Hudson, you can run arbitrary Groovy scripts. In order to do so go to the Hudson Dashboard and click on the Manage Hudson which brings up the screen as shown below:

Click on the Script Console, which will bring you another page where in you can run any Groovy script to troubleshoot Hudson.

Hudson Environment Variables:
You can easily incorporate the environment variables which are easily available within your build scripts as such:

<target name="retrieve-env-variables">
<property environment="env" />
<echo message="${env.BUILD_TAG}"/>
<echo message="${env.BUILD_NUMBER}"/>
<echo message="${env.BUILD_ID}"/>
</target>

Spaces in directory names:
If you use the default setting for Hudson-Home; it is in the “Documents and Setting” folder. This causes Ant build files to fail. Make sure you set your Hudson-Home to a directory without spaces.
Also, while creating a new Job in Hudson, it has been seen that Job names which have spaces cause trouble while running the Ant build scripts.

Use anything but IE:
Last but not the least, if you are using Internet Explorer as the default browser, switch to some other browser. I spent a day trying to fix the matrix based security and also trying to rearrange the Build Steps, and enter a Groovy Command. All worked seamlessly when I switched to Firefox.

Links to additional tips and tricks already posted here:

1. Retrieving error level
2. Versioning Hudson job cofigurations
3. Hudson’s so Groovy
4. Matrix based security and IE

If you are in Ireland (or close enough to get there easily!) the week of June 9th, then you’ll want to come to the International Conference on Agile Processes and eXtreme Programming in Software Engineering as I’ll be giving a tutorial on Continuous Integration!

The tutorial will walk students through a series of exercises on a project where an automated build system is created that facilitates compilation, testing, inspection, and deployment. This build system will then be plugged into a CI server (Hudson in this case) 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 a pint of Guinness!

If this sounds like a blast to you, then register today! If you plan on attending, drop me an email and I look forward to meeting you!

Calling all blokes and sheilas– this year’s Asia-Pacific CITCON will be in Melbourne, Australia on June 27th & 28th– registration is now open so claim your spot before space runs out (space is limited to the first 150 tall poppies, surfies, and all around dags)!

If you dream about CI, yabber about TDD, live for BDD, or constantly think about automated deployments, then the Continuous Integration and Testing Conference is a ripper of a time, mates! The conference is free and is run as an OpenSpaces event, so there’s no reason not come. Remember, space is limited so sign up now!

Let’s say you have a fairly complicated build structure, with multiple batch files that fire off different aspects of the build (even if, at the end of the day, they just call ant).

And let’s assume that for various historical reasons, these batch files encapsulate their environment variables using SETLOCAL and ENDLOCAL.

At first glance, this is a pretty cool way to scope out your environment variables. But then, you find out that Hudson determines if a build has succeeded or failed by looking at the %ERRORLEVEL% environment variable. If it is not 0, the build has failed.

Uh oh. Your build is failing, but the moment ENDLOCAL is called, %ERRORLEVEL% is set back to its previous value, which, most likely, will be 0.

Given this situation, how do you get the %ERRORLEVEL% back up to Hudson? Well, don’t call ENDLOCAL. Instead use:

EXIT %ERRORLEVEL%

at the end of your batch file. This works because there’s an implicit ENDLOCAL at the end of your batch file, and EXIT will return the ERRORLEVEL as the exit value.

Wednesday, April 16th: 3:00pm – 4:00pm ET

Are you seeking to improve the development practices of your organization? Has your team adopted a continuous integration strategy? Are you looking for the best tool to manage your builds? If so, this webinar hosted by Paul Duvall, author of the Jolt award-winning book on Continuous Integration, needs to be penciled into your calendar.

Entitled, “Continuous Integration: Improving Software Quality and Reducing Risk,” the webinar will tackle key topics and practices in the areas of continuous database integration, testing, inspection, deployment and feedback.

If you’re a lead engineer, architect, or development manager striving for greater confidence in your software product, you should tune in to find out more about how CI helps reduce key project risks such as late defect discovery, low-quality software, lack of visibility, and lack of deployable software. Additional topics on the discussion table include:

• How to use CI leveraging a combination of CI, build, test and inspection tools
• How to make integration a “non-event” on your software development projects
• How to reduce the amount of repetitive processes you perform when building your software
• Effective practices and techniques for using CI with your teams

Registration is required for this event and available at: https://www1.gotomeeting.com/register/656993026?Portal=www.gotomeeting.com

If you are using IE and trying to configure Matrix-based security, beware. It doesn’t work no matter how many times you click the Add button.

At this point, don’t panic. Rather than changing the config.xml and manually adding all the users and setting their permissions, download Firefox, and you will be easily able to configure the same as shown below:

Hello!

Andy has graciously invited me to post here at testearly.com, and I thought I would start off with some of my experiences with configuring Hudson. This is a crosspost from my blog, but I suspect it will get a lot more traffic here.
…

Let’s say you’re using Hudson as your build/Continuous Integration tool. And let’s assume you have some jobs running inside Hudson that you want to keep running, even if the build machine blows up. You probably want to maintain:

• Hudson itself
• All the plugins
• The overall configuration
• The per-job configuration

Naturally, then, your thoughts should turn to “How do I put the Hudson configuration into source control?” Here’s what you do:

1. Make sure your builds are configured and working to your satisfaction, in a directory that I will from now on refer to as HUDSON_HOME.
2. Copy the entire HUDSON_HOME directory tree to a temporary location called “versioned_build”
   1. In the versioned_build directory, you’ll find the jobs directory, and under that, a directory for each job.
   2. Inside each job directory, you’ll find configuration .xml files and other miscellaneous files, and you’ll find two subdirectories:
      • workspace
      • builds
   3. Empty those two subdirectories of all files, but do not delete the subdirectories.
3. Repeat this “clean out” process for each job.
4. import the entire “versioned_build” directory tree into source management.

Now, you have your Hudson configuration in source control. You can start it up, and assuming HUDSON_HOME is set right (see below), you should see your dashboard, and your jobs listed, and properly configured. Issues

• You may have to manually kick off your jobs to “prime the pump”
• Your build number will not start at 0 unless you do not archive the nextBuildNumber file
• Your HUDSON_HOME environment variable may be incorrect for your machine (see below)

HUDSON_HOME Portability For ease of checkout and maintenance, I like the following directory setup: $HUDSON_HOME/

• hudson/
  • hudson.war
• jobs/
  • Your Hudson Jobs Here
• plugins/
  • Your Hudson Plugins Here

Using this configuration, you can create a file in $HUDSON_HOME called, say, hudson.sh, which would look a little something like this:

---

#!/bin/sh
export HUDSON_HOME=.
export CVS_RSH=/usr/bin/ssh
java -jar hudson/hudson.war

---

Using this structure, and that hudson.sh script (I presume you can do something similar in Windows) gives you the following benefits:

1. Your entire Hudson system, including the Hudson war file and the launcher script are all maintained as part of the repository.
2. You don’t have to set HUDSON_HOME whenever you check the system out of source control - it’s already set by default to the current directory. As long as you run hudson.sh in its own directory, you’ll get the correct value for HUDSON_HOME

Learn from my mistakes!

• Unless you absolutely must, don’t tell Hudson where to find Ant or the JDK. If they’re on your path, Hudson will find them on its own. If you set them for your build machine, chances are that on the checkout machine they won’t be in exactly the same place

InformIT has published a Q&A with Stelligent’s CTO, Paul Duvall. Paul shares his thoughts on adopting CI, the future of CI, and of course, his thought provoking blog entry. Check it out!

Hudson is an open source CI server that offers quite a few compelling features (in addition to its easy setup and configuration) that come in handy from time to time. For instance, Hudson offers a Groovy plug-in that facilitates executing arbitrary Groovy scripts (or code) as a part of a build.

Groovy can be quite useful for simple tasks, which when written in some other form (like an Ant script) requires a lot of plumbing– for example, recently, as a part of a CI project setup, another dependent project’s directories were becoming read-only due to an SCM feature. Consequently, a child project couldn’t write to the filesystem.

This problem was easily solved using Groovy (plus a little Ant)– a triggered build executes a small Groovy script that uses Ant’s chmod task to make target directories read-write enabled. As you can see, the fix requires 2 lines of code (which could, arguably, be reduced to one):

def ant = new AntBuilder()
ant.chmod(dir:"./ci09_i/ui/rep2/reports/", perm:"ugo+rw", includes:"**/*.*")

Hudson’s so Groovy that it’s hard to ignore this CI server as a viable option!