Continuous Integration on Hudson

Continuous Integration (CI) is a software development practice that automate the build command periodically. As many users check in and commit the source code, it will be very difficult to track the error without knowing who cause the failure. The CI provides log of each build that developers can review to find out what had happended to the system at a specific period.

Hudson is a continous integration server for ICS Software Engineering. It provides a plateform for any software development project that using Marven or Ant build tool and Subversion. Creating a new job on Hudson server is very easy; however, scheduling the build trigger is a bit confuse especially between build periodically and poll SCM.

I was assigned to work on the wattdepot-cli project with BJ Peter Delacruz (the leader) and Wahib Hanani as team ekolu (or team #3). We've created a job on Hudson called wattdepot-cli-ekolu, scheduled the build trigger on every five minutes, and set up the failure notification to be sent to the wattdepot-cli Google group. It was a mistake on the scheduling as the trigger generated hundreds of builds; thus, the log seem to be useless. Later on, we changed the schedule to trigger the build command only when there is a change in the source code which also allows us to know when was the last update on the system.

Personally, I believe that a great tool like the CI alone can't make a smooth development process without involving other interaction such as properly configure the build trigger, break up the package into small pieaces, or constanly update the system.