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.

As of December 1st, the Microsoft Store in Redmond will for the first time start carrying books from publishers other than Microsoft Press. My book, Continuous Integration: Improving Software Quality and Reducing Risk, is one of those books. For the time being, the book will only be available at the physical store, not at the online Microsoft store.

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.

In case you can’t get enough of CI from the book, check out “Spot defects early with Continuous Integration” at IBM developerWorks.

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.

Agitar’s Jeffrey Fredrick and myself will be hosting a free webinar on how to implement a continuous integration and testing process. Jeffrey is a key factor in the success of CruiseControl and is one of the principle figures behind CITCON (the other, of course, being Paul Julius); consequently, I’m humbled to have this opportunity. If you’re curious about CI or developer testing, then make it a point to join us for this event.

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

I am very pleased that renowned Continuous Integration and Developer Testing expert, Paul Julius, has joined Stelligent Incorporated (my employer). Paul and Jay Flowers are recent additions to our impressive team of experts.

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.

My employer, Stelligent, is hosting a roundtable discussion on TDD at our offices in Reston, Virginia called “TDD horror stories” on Tuesday, October 30th.

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.

Steve Berczuk, Robert Cowhan, and Brad Appleton (Berczuk and Appleton are authors of the excellent book, Software Configuration Management Patterns) recently published an article called “Agile SCM is Testing” at CMCrossroads. In the article the authors clearly make the assertion that testing and SCM are not separate:

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.