Actually, Guidewire has already built an internal tool, ToolsHarness, to handle continuous integration, as I have written in "Managing Tests with ToolsHarness, Individually". The only difference that I want to introduce for Phoenix project is to fix broken tests AS SOON AS POSSIBLE.
What this means is that I want the testing status of our branch to show right in out faces, without us having to launch a browser, so that we know to take action the moment a test is broken.
I talked to the developer who manages ToolsHarness, and he wrote a servlet that serves information about broken tests and test status like this picture, except in one HTTP GET. Then I set up CruiseControl(version 2.8.2) with X10 publisher, following the setup described on this blog post "Bubble, Bubble, Build's In Trouble".
One thing about the normal lava lamp setup has always bugged me in the past, which is when the continuous integration server is in the "testing" state. When you have test broken, the red lava lamp will be on, and you just have to remind yourself that the fix is in and test is running. In some projects, I have used "project soundscape", so that when tests finishe but are still broken, you will know about it. But if you happen to step outside, you will miss it. Or if you just came in, you have to check the browser or ask others.
So this time, I have done it a little differently, taking advantage of the fact that CruiseControl is not the process running the tests. I bought two lava lamp, one kind of in the red color and the other in blue. I set it up so that when there are two independent lava lamps:
- Red Lava Lamp for broken tests: When there are broken tests, it will be on, otherwise, it will be off
- Blue Lava Lamp for testing status: When there are tests running, it will be on, otherwise it will be off
- Neither is on: All tests pass and the tests are up-to-date
- Blue is on and red is off: All tests pass so far, but there are tests running against newer changes
- Blue is off and red is on (see below): You have broken tests, and no code checked in to fix it
- Both blue and red are on (see below): You have broken tests and someone has cheked in new code (hopefully to fix it)
The setup is pretty straightforward, except CruiseControl 2.8.2 release is missing two crucial files, "lib/win32com.dll" and "lib/javax.comm.properties", for X10 publisher to work. That, and me missing a tiny but also crucial detail in the documentation, caused my three-hour-hair-pulling experience, and that was with Jeffrey coming to rescue through GTalk. I am going to submit the patch for the release script to include those two files, and documentation with the following checklist:
- You should provide all FOUR attributes related to X10 for the
element, so that you are aware of them and make sure they are correct. These four attributes are as following:
- "houseCode" and "deviceCode" are for X10 module configuration.
- "port", with the value of COM1, COM2, etc., to match the place you plugin the COM module.
- The last one is "interfaceModel", which you should really double check with the COM module that you have.
- Make sure "javax.comm.properties" is in your CruiseControl lib directory (should be there after 2.8.3)
- Make sure you copy "win32com.dll" from CruiseControl lib directory (should be there after 2.8.3) to your Java bin directory