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

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!

On Wednesday evening, I had the pleasure of attending the Jolt Awards ceremony where Continuous Integration: Improving Software Quality and Reducing Risk was a finalist….and WON for best technical book!

Stelligent’s own, Paul Duvall, and co-author, Steve Matyas were on to hand to accept the trophy- which is essentially a giant can of Jolt cola encased in a Lucite block. You have to see it in person- the design is very cool (and it’s heavy!).

Many congratulations to Paul, Andy, and Steve; as well as the contributors, editors, and publishers who brought this book to life! This year’s winners will be featured in the June 2008 issue of Dr. Dobb’s Journal.

There’s a lot to look forward to if you’re attending the SD West conference in Santa Clara next month. To kick it off, Stelligent’s own, Andrew Glover, will be delivering a half day tutorial introducing Groovy on Tuesday, March 4th. If learning Groovy quickly interests you this is one presentation you can’t miss out on!

On Tuesday evening, I encourage you to attend the “Agile Roundtable” hosted by Stelligent. If you haven’t participated in a Stelligent roundtable previously, this is the one you need to get yourself to. Topics on the discussion table include Test-Driven Development and Continuous Integration. For more information, or to RSVP, please contact mandy.owens@stelligent.com.

Finally, the winners of the industry-acclaimed Jolt Awards will be announced on Wednesday evening, March 5th. We’re quite partial to the “Technical Books” category where we hope Continuous Integration: Improving Software Quality and Reducing Risk jolts the industry!

Production-ready software, on-demand

The general notion of the practice of Continuous Integration is that it’s performed during the “development cycle”. I think we need to expand this into areas typically thought of as “latter lifecycle” activities. In my experience, even the most Agile of projects aren’t considering all aspects of what it takes to make software “production ready”.

Over the past year, I’ve been advocating a much more intensive criteria for Continuous Integration with my peers and customers, which is more like “Continuous Production” meaning you can produce production-ready software on a daily or even a continuous basis. Effectively, we’re talking about extending the Continuous Integration model into all environments (Test, Stage and Production), not just the development environment. In fact, at Stelligent, our purpose is to get our customers to production-ready software on a daily basis.

A posting on Wikipedia describes Continuous Production as “a method used to manufacture, produce, or process any product without interruption. There is no discrete rate at which goods are produced, as opposed to a batch production process, or job production.” I’m suggesting we move toward a similar model for developing software.

A lot is bundled in this term, Continuous Production, though. In my experience, it means that you automate most everything it takes to create software so that it can be deployed into the user’s environment any time. It means you may automate some or all of the following:

1. Compilation of source code and tests - this is a given for CI.Tools: Ant, MsBuild, rake, NAnt or similar build tool.
2. Database Integration/Migration to target database server (e.g. Oracle) - Some shops are doing this with CI. Tools: Ant sql task or ORM-based Ant tasks, dbdeploy
3. Testing - execution of unit, component, system, functional/acceptance, security, load and performance tests - Some shops are doing this with CI. Tools: JUnit, DbUnit, Selenium, JUnitPerf, FindBugs, JMeter, NUnit, NDbUnit
4. Inspections - execution of static/dynamic analysis checkers: code coverage, code duplication checks, coding standards, cyclomatic complexity and dependency analysis - Some shops are doing this with CI. Tools: PMD, CheckStyle, FindBugs, JavaNCSS, JDepend, Cobertura, NCover, NProf, Source Monitor, NCover
5. Deployment - Deployment and repeatable configuration to servers (e.g. JBoss) - Some shops are doing this with CI. Tools: Application Server-specific Ant tasks (e.g. WebLogic)
6. Remote Deployments to target environments - For example, from a build machine to staging environment (for web containers and database servers). Tools: Ant, Java Secure Channel and SmartFrog, Capistrano
   1. You will need a way to rollback to a previous deployment (this includes database changes)
7. (Optionally) Creation of installation distribution - Few shops are doing this with CI. Tools: NSIS and antinstaller, InstallShield .
8. (Optionally) Generation of distribution media - Few shops are doing this with CI
9. Source labeling and (possibly) build labeling - Some shops are doing this with CI
10. Automated notification of build status - This is a given for CI via Email, X10 devices, etc.
11. Automating the promotion through QA, Staging and Production environments - Promote the binary and accompanying artifact through each target environment. Tools: Build Management servers such as AntHill Pro are useful for build promotion
12. Documentation Generating the readme docs, installation and user guides. Tools: JavaDoc, NDoc, Doxygen, GraphViz, Grand, etc.

Of course, the actual steps will vary depending the type of software application you are producing whether it be a rich client, web application, embedded or other…but you get the point. Continuous Production, to me, means you have the capability to create production-ready software whenever necessary .

What I am saying is that the creation of production-ready software should become a “nonevent “.

The benefits are numerous, but here are a few:

• Decisions can be made based on working software , not on a task item on a project management chart - no more “it’s 80% done”
• Eliminate the reliance on an individual with specialized knowledge to produce the software for production
• There’s “done”, there’s “done, done” (coded with acceptance tests). With Continuous Production, it’s “done, done, done” and ready for release to users (code, acceptance tests, operating in the customer’s environment)

Note: This does not mean that you will be taking up cycles producing production-ready software with every change to the version control repository. Test, Stage and Production builds are more likely to be performed on demand (by a person). However, the point is that your build environments are capable of building production-ready software on a continuous basis.

There are very, very few projects that are doing this right now. I’d have to guess it’s much less than 1%. It makes me think of the saying “it’s not the destination, it’s the journey”. If your team sets this as a goal, the closer you get to it, the less you’ll be spending time on environment-related, repetitive and error-prone issues and the more time you spend on new features and improvements to the software. Is it possible, right now, for every project to do this? Probably not. However, once you start asking questions like “What do I need to do to make this feature production ready?”, it changes your perspective on everything from coding to testing and deployment.

In reality, I think even the most automated development environments still need (or should) have a manual component when creating software that is production-ready. This may include usability testing or even a simple manual sanity check. But, I think the more we move toward this model, the less headaches we’ll have and the better our estimates.

In my book on Continuous Integration, I make a reference to something Tim O’Reilly mentioned regarding Flickr’ s ability to deliver updates to its web software as frequently as every 30 minutes. This is only possible if you’ve automated many of the deployment steps.

Let me know if you or someone you know is doing this or moving toward this type of model. I’m curious to hear your experiences with it.