Monday, November 2, 2009

Hudson + SCM = <3

For this week in the Software Engineering class, we were introduced to another Software Engineering tool, Hudson, which is a continuous integration tool. Currently I am working on a branch CLI (command-line interface) for the Wattdepot-CLI project, there are about 13 other branches also in the making.

Continuous integration is when you have your software project automatically updated after someone does a commit on the project. Shortly after a commit has been made you can setup your CI (Continuous Integration) tool to poll your Software Configuration Magangement and see if the commit that was made breaks the system. This is extremely helpful when it comes to having the most up-to-date WORKING system.

Some of the features Hudson includes is an online console where you can view in real-time or an archive of a build so you can see where the build messed up. You can have it setup to build continuously or simply poll the SCM to see if the system Hudson has is the most recent version. In our case we have it setup to poll every 5 minutes.

When a commit does break the system Hudson is able to send out an e-mail notification to all users on the project (we use a Googlegroup to accomplish this) this in effect creates a more stable system since all developers will see the error and hopefully try and correct it. Hudson also records how many test cases are run and graphically shows this on a #number of cases vs. time relation.

Setting up Hudson was relatively straight forward, the screencast that was made really broke it down in steps. All you really need to know is the URL to the trunk of your project. What's also nice about Hudson is that it checksout your project anomously so you don't have to give it sensitive information like a username/password to build your project.

I didn't know what to expect from Continuous Integration, other than listening to Prof. Johnson's Screencast about it being great it is, but after almost a week under CI, I can see that it is indeed a powerful tool to use to create a more stable, growing system.

I can't really say there's a bad thing about using Hudson other than the ton of spam I get for every build success and fail I do along with all the other branches, but that's easily dealt with. For this small two-person project, I can say I could live without it, but for larger projects that require groups of developers I can't see myself not using a CI to ensure every section of the software is up and running.

No comments:

Post a Comment