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.

One of my goals from the beginning in writing the book was to provide examples in many different languages/platforms. In the book, we cover C#/NAnt examples, .NET static analysis tools along with Java and Ruby examples. There’s something for everyone. CI, as a practice, is independent of any particular tool. That said, tools greatly support the practice, given the vast array of code inspection, build, and CI servers on the market. So, if you’re a Microsoftie and are curious about CI or are currently using the daily build practice, purchase a copy, or three, for yourself at the Redmond store.

This tutorial guides you step-by-step through the fundamental concepts of Continuous Integration using Hudson, Ant, and Subversion– when you’re done, you’ll understand the 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 violations almost as quickly as they occur.

The webinar will take place on November 14th at 9am PST and registration is required. See you there!

Paul is a co-founder of the CruiseControl Continuous Integration server and has a passion for improving the state of the software industry. Paul is also a co-founder of the wildly popular CITCON conferences hosted on three continents every year. Along with Martin Fowler, he wrote one of the forewords of the Continuous Integration book that I coauthored. I look forward to working with Paul as he joins Stelligent. He blogs at www.pauljulius.com/blog/ and will soon be blogging at our popular company blog, TestEarly.com.

Stelligent is the leader in Agile Software Production. We work with large Fortune 500 and government organizations around the world. We help development teams employ techniques such as build automation, continuous integration, release engineering, automated developer testing and inspections into the daily process of developing software rather than waiting later in the lifecycle. Our goal is always to accelerate the delivery of highly reliable software for our customers.

TDD, or Test-Driven Development, is a great companion topic to Continuous Integration as your integration is rarely useful without running a suite a automated developer tests.

It’s another wine (brought to you by Savoy-Lee wineries) and cheese party. Stelligent is also raffling off a an iPod shuffle

From TestEarly:

I often run into teams who attempted to jump skull first into TDD and eventually threw their bones up in frustration when either schedules became scary or they ran into scenarios too frightening to test. Are there areas where test-driven development gives you the spooks?

As you can see, it’ll be fun!

When: Tuesday, October 30th from 5:30 PM to 7 PM

Where: Stelligent’s haunted headquarters (map)

Who: Developers, Technical Leads, Architects, Project Managers, Testers…Anyone involved in software development

You must RSVP.

People care that their system works as expected, the functionality was added as desired and not removed accidentally. We want to ensure that the value of our configurations is increasing over time rather than decreasing! To verify these things you need to test the working application. In this sense you can’t fulfill the goals of SCM without testing.

Along with several other salient references, the authors point to our book on Continuous Integration: Improving Software Quality and Reducing Risk. In particular, they reference our advice on quality and policy metrics (note, much of this is in the “Continuous Inspection” chapter) as enablers to a more effective development ecosystem.