Guerilla Continuous Integration
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:
- Download the latest binary at http://hudson-ci.org/latest/hudson.war
- Execute "java -jar hudson.war"
- 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:
- Give your job a name;
- Select Maven 2 project;
- Choose CVS or SVN and provide the repository details;
- Setup SCM polling and provide a cron pattern (I like to use "*/5 * * * *" to check SCM every five minutes. Visit http://en.wikipedia.org/wiki/Cron for more on cron patterns.);
- Provide the Maven goal you'd like to run ("install" is a good choice to begin);
- 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:
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)