>Ever have one of those days where nothing seems to go right. Plans you had just get tossed out the window. I was happily working on the XSL Tools documentation and had submitted a change along with a minor change to testing, released the code, and waited for the build to return. No build ever came back. Checked Cruise Control…yep, it’s down.
In the past this would have left me stuck. Having grown used to the verification that is provided by an automated build, and that nice Green indicator, this was messing up my work flow. I decided that to at least give me some verification, I would fire up my local build. The nice thing about the local build it will pull everything from head, about every 10 minutes if there are changes. I fire it up, and 10 minutes later I get my report. Failed. Apparently the minor change I did to the unit tests wasn’t so minor. The only thing I had changed was to add a range for Junit to be from 3.8.x – 4.6. Which unfortunately, the eclipse testing framework that runs the tests, has some problems with mixing of these tests. So I reset it back to only Junit 3.8.x and recommited code to head.
The local build happily found the new changes and kicked off another build….this time with a nice little green indicator.
Building from head this way helps give immediate feedback of any integration errors that may occur. Just because I ran the tests fine within my workspace, did not mean they were going to run fine outside of it. The local build was my safety net. Otherwise, I would have had to wait until Cruise Control could be restarted, and which could have been hours later. Making it much more difficult to figure out why the build failed. Who knows how many other changes would have been done between now and then.
So keep your builds fast, and build as often as possible. The feeback you get is invaluable in helping keep your builds green and catching various types of errors early. Of course this only works well if you consistently have unit tests to go along with the changes you make.