Agile Zone is brought to you in partnership with:

Matt is the Group Leader of Research Application Development in the Research Informatics Division of Information Sciences at St. Jude Children's Research Hospital in Memphis, Tennessee. Matt has been developing and supporting enterprise Java applications in support of life sciences research for St. Jude since 2001. Matt is a committer to multiple open source projects and is the founding member of the Memphis/Mid-South Java User Group. Matt is also a regular speaker on the No Fluff Just Stuff symposium series tour (as well as other major conferences), and his articles have appeared in GroovyMag and NFJS the Magazine. His current areas of interest include lean/agile software development, modularity and OSGi, mobile application development (iPhone/iPad/Android), web development (HTML5, etc.), and Groovy/Grails. Matt has posted 44 posts at DZone. You can read more from them at their website. View Full User Profile

Guerilla Continuous Integration

  • submit to reddit
Welcome to episode six of The Agile Guerilla series. The focus of this series of articles is to to help you introduce change, specifically moving to agility, into your organization from the grassroots level.

In our first episode, we defined guerilla warfare and looked at why using guerilla-like tactics can be an incredibly effective way to spur on an agile transformation from the bottom up. Then, in episode two, we zeroed in on the two fundamental tactics employed by the agile guerilla. Episode three's focus was on how to get started. We examined four different ways that we can turn inward and address our own flaws as a developer and as a person. Episode four showed us...wait for it...FOUR ways that we can improve our personal workflow and influence our team to manage its work more effectively. Finally, episode five focused on Guerilla TDD, or how you can apply the agile practice of Test-Driven Development even without your team on board.

In this episode we'll be looking at another agile practice - Continuous Integration (CI). I talked about CI in my early article entitled "Feedback is the Key!"

CI has evolved through the years to describe the practice of having a server tool continuously monitor your team's source code repository for changes. When a change is detected, it checks out the latest copy of the code, builds the software, executes any available automated tests, and then generates a report of the results. The very best teams have this report sent to each member via email, IM, etc. You can think of CI as broadcasting the information generated by your "Developer to Code" feedback loop to your entire team. As a group you receive continuous feedback about how your combined efforts are coming together to build a working system. Any problems that require a whole-team response are immediately brought to your attention. It's also an excellent opportunity receive feedback about how your product may behave in a production setting by placing your CI system in as close of a mirror as possible of your production environment.

If you're not familiar with Continuous Integration, I strongly urge to to read Martin Fowler's still incredibly relevant article on the topic.

If you haven't already noticed, my above quote contains at least seven references to the entire team's involvement in Continous Integration. How in the world can an Agile Guerilla get this done?

First of all, there are a couple of prerequisites:

  • Your team MUST be using source code control that is more sophisticated than a shared file server. If you're not employing CVS, Subversion, Git, etc. then you have far greater problems. Believe it or not, there are still many teams out there in exactly this position (I personally convinced a team to start using source control only three years ago). This is definitely a battle that you're going to have to fight with a full-frontal attack. That said, I'd still recommend doing your homework and preparing a persuasive briefing for your manager or team lead. There's no need to be abrasive about it!
  • An automated build is also a must. If you're in the Java space, something like Ant, Maven, or Gradle will do the trick nicely. Minimally, the build will need to be capable of compiling all of the code, running any available automated tests, and then publishing a report of the results. This is also a technique that for effectiveness you really need everyone on board. However, it is possible (but extremely difficult) to do a guerilla build. Perhaps I'll write about that experience another day.

So let's say you have the necessary environment in place. What now? Believe it or not, the answer lies in episode two:

Before you ever say a word about continuous integration to your team, you need to do it yourself FIRST. Learn the techniques inside and out. Install Hudson on your own workstation and experiment with its features. Set up your current project in it and have it start building every time code gets checked in. Connect Hudson to your company's mail server (or if that's a non-starter, go with GMail!) and start the build notifications flowing.

Installing Hudson is radically simple:

  1. Download the latest binary at
  2. Execute "java -jar hudson.war"
  3. Navigate to http://localhost:8080

You'll now be looking at the Hudson dashboard. You'll want to do some basic configuration (where's Java, where's Maven, where's the email server, etc.). Fortunately, Hudson configuration is a snack! Just click on "Manage Hudson" and you'll find everything you need to do on one screen.

After setting things up, you'll click on "New Job" to get started. If you have a Maven 2 project, it's a simple as:

  1. Give your job a name;
  2. Select Maven 2 project;
  3. Choose CVS or SVN and provide the repository details;
  4. Setup SCM polling and provide a cron pattern (I like to use "*/5 * * * *" to check SCM every five minutes. Visit for more on cron patterns.);
  5. Provide the Maven goal you'd like to run ("install" is a good choice to begin);
  6. Turn on email notification and add your email address.

That's it! Check something in to your project and within five minutes you should see your project build!

Now, how do we get the team involved?

Now, the next time the build fails, walk over to the poor guy that committed the code with a printout of the email (I know we're trying to go green, but forwarding the email won't work! You've got to have a face-to-face.) and say, "Hey Joe, I've got this new tool that monitors our project and it says the code that you just checked in doesn't compile. Do you mind taking a look at that?" That's it - no confrontation. Just state the facts. Keep doing this periodically. Before you know it, folks are going to start begging you for those emails. Politely add them to the list and pat yourself on the back. You've just infected your team with continuous integration.

It's that simple, and it really works!

That's all for this episode of The Agile Guerilla. Next time we'll close out the series with a look back at where we've been. See you then!

Other Epsiodes in "The Agile Guerilla" series:

Published at DZone with permission of its author, Matt Stine.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Yeong Sheng Tan replied on Mon, 2010/08/16 - 9:11pm

1) How do you handle a project that contains portlets developed in MishMash technologies that require both Ant build and Maven build depending on the underlying supported technologies used for the framework of the portlet being developed?

A case in point is something like Liferay, that contains Struts 1.1.x legacy core stuff, with blooming custom portlets developed in IceFaces, Wicket, Vaadin, Struts 2, Spring MVC, etc - you get the point.

Worse still, when each framework supports differing build maturity tools - e.g. Liferay comes out of the box with Plugins SDK in Ant, and the custom portlets contains Maven archetypes, or we may be experimenting Gradle for that matter.

How do we consolidate into a unified build system? I suppose a good middle-ground in Maven, but until all custom portlets and core Liferay supports it well, it becomes a chore to spawn multiple Hudson job to build 1 concrete deployable entire Custom Liferay solution.

2) What was also not discussed is the EIS or DB layer. What toolset is mature enough to incorporate into the full build and test, where entire DB and base data is torn down and ERs rebuilt as part of CI build and data auto-populated for fully automated Unit Testing and Regressional Functional testing to happen? DBUnit, <some data mix generation tool?>, <some data load generation tool?>, JUnit/TestNG, Selenium/iTest2???

3) Then there is the perenial question of putting Performance Load testing into the loop of CI? What toolset is there to support this? Glassbox??? How do we generate mock load data with prod-ready proportionally mixed data for a good representative load testing to happen?

4) What of post build, where the final binaries need to be packaged into a usable click/execute and go installer package - in the likes of PackJacket, etc?

Believe the above 4 points are still up in the air as to how to tackle and solve these problems with good proven open source tools. There is much space to be addressed from build, to data to load to deployment packaging space.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.