My employer, Stelligent, is hiring Senior Agile Consultants to work with our growing team of experts. See the job description here.

When people ask me why I enjoy working for Stelligent, the answer is simple: no two days are the same. At Stelligent, our consultants are able to work in many diverse environments whether it be an industry, a customer or a technical platform. We’ve worked on Java and .NET projects and we’ve created solutions using Ruby and Groovy. We are on the cutting edge of technology because our customers demand it. We’ve worked with financial services firms, health care, and philanthropic organizations. It makes for an exciting and dynamic environment.

Further, you’ll work with some of the leading experts in the areas of Continuous Integration, Test-Driven Development and other Agile practices. Contact Stelligent today to learn more about our employment opportunities.

How do you combine the need to perform on-demand builds with Continuous Integration using voice commands?

For about six months now, I’ve been an ardent user of Jott. Jott transcribes voice to text and is an extremely useful utility for creating items on my todo list (especially as I commute in the DC area ). Recently, I linked this useful tool to something else I do quite often, running on-demand deployments. The solution is part useful tool and, quite frankly, part gimmick. I came up with the idea after watching an episode of the television show 24. Here’s how it works:

1. I dial an 800 number provided by Jott from my cell phone. When prompted, I say “Build Stage” and hang up. Jott sends my transcribed voice to my email account.
2. On a scheduled basis, an Ant script parses my email searching for keywords. It finds “Build Stage”, so it runs an Ant target to execute a remote deployment in the Stage environment.

Here are the tools to make it all work:

1. Jott (or any tool capable of transcribing voice to text)
2. Cygwin w/ fetchmail
3. Ant
4. Schedule to run via your CI server
5. POP-enabled email

Sign up with Jott

Go to Jott.com and register to use this free service.

Download Cygwin

See the instructions on how to use Cygwin, fetchmail and pop-enabled GMail to read your email via the command line. These instructions describe how to create backups of your GMail using the fetchmail utility. You can follow the same instructions, however the reason we’re doing this is to create a text file that is readable by a headless process via Ant so that we don’t need to open a browser or email client to have Ant read the email contents. Although the instructions are for GMail, the point is to pop-enable your email so you should be able to use other email services that provide POP capabilities.

You should also run fetchmail as a daemon process so that it gets your email as soon as it’s sent.

Create an Ant target to parse your fetchmail email

Using Ant, load the fetchmail file (which contains your email text) and parse the file using regular expressions to search for keywords. If the keyword is found, set a property. Then, use this property to conditionally run a target that executes a build.

…

<target name=”parse-email”>

<loadfile srcfile=”C:/cygwin/var/spool/mail/[your email file]” property=”stageBuild”>
<filterchain>
<linecontainsregexp>
<regexp pattern=”Stage*”/>
</linecontainsregexp>
</filterchain>
</loadfile>

</target>

…

Schedule to execute your Ant script periodically

Call the Ant script above from your CI server (like Hudson or CruiseControl). Run it on a frequent basis, such as every minute or so, so that soon thereafter your voice command is transcribed, the build is executed.

More…

I came up with this idea in the past week and I know there are more robust ways of implementing it. Also, I glossed over some of the details. For instance, instead of using a CI server, you could simply run a scheduled task to run the Ant script that parses your email. Further, in a *nix environment, you obviously wouldn’t need to use Cygwin at all and, instead, use the native utilities. Also, the regular expressions can be further refined so that there are no false build executions. In any case, I hope this gets your creative juices flowing and you come up with ideas that extend this any further. Please let me know what you discover and share it with the community.

In demonstrating the Use a CI Server practice from Continuous Integration: Improving Software Quality and Reducing Risk , I show you how to create a full-featured CI system using CruiseControl, Ant and various testing, inspection and deployment tools such as Cargo, DbUnit, JUnit, JavaNCSS, Selenium, Simian, JDepend, Subversion, Cobertura and CheckStyle .

The demonstration includes a fully-functioning (albeit small) web application. You will be able to access the full source of build scripts, CruiseControl configuration scripts, Java and other configuration files so that you can configure this in your environment as well.

If you’re interested in the mechanics of installing and configuring a CI system, this is the video for you .

If you find yourself in need of a generic management tool that facilitates installing, starting, and stopping a container, plus the ability to deploy artifacts like war and ear files, then you may want to take a look at Cargo.

Briefly, Cargo is an innovative open source project that aims to automate container management in a generic fashion, such that the same API used to deploy a war file to JBoss can also start and stop Jetty. Cargo also can download and install a container automatically; and you can utilize Cargo’s API in a few different fashions, ranging from Java code to Ant tasks to Maven goals.

For example, if you’d like to create a repeatable deployment process that avoids environmental assumptions (like that the instance of the application server is properly configured, etc), you can use Cargo to automatically download and install a pre-defined kosher version, say of JBoss. Once JBoss has been installed and is started, you can then deploy artifacts and begin testing.

Using Ant to accomplish this process is actually quite simple. All you need are two jar files (at a minimum). If you are using the latest version of Cargo (at the time of this posting) then the two files are: cargo-core-uberjar-0.9.jar and cargo-ant-0.9.jar.

With these two files in your classpath, you can then create an Ant target that initializes Cargo’s task like so:

<taskdef resource="cargo.tasks">
 <classpath>
  <pathelement location="${libdir}/${cargo-jar}" />
  <pathelement location="${libdir}/${cargo-ant-jar}" />
 </classpath>
</taskdef>

Then you can download and install a container, plus start it as follows:

<cargo containerId="jboss4x" action="start" wait="false" id="${jboss.refid}">
 <zipurlinstaller installurl="${jboss.installer.url}" />
 <configuration type="standalone" home="${jboss.tmp.dir}">
 </configuration>
</cargo>

Note, you can deploy ear and war files between the two configuration tags. Also note, if JBoss is already installed, Cargo won’t attempt to reinstall.

Lastly, if you’d like to stop JBoss, then you can issue the following command:

<cargo containerId="jboss4x" action="stop" refid="${jboss.refid}" />

A refid is required to find a process as these steps are logically broken up. Also note that Cargo requires two different directories to properly install and configure JBoss– you can not use the same directory.

Cargo makes automated and reliable deployments a non event because this framework manages the container environment so you don’t have to. Give it a try and you’ll see a drastic increase in your ability to choreograph deployments quickly.

For more information on using Cargo for repeatable testing check out

• In pursuit of code quality: Repeatable system tests (DeveloperWorks, September 2006)
• In pursuit of code quality: Programmatic testing with Selenium and TestNG (DeveloperWorks, April 2006)