This entry is a geek entry, so I'm talking about cruisecontrol the build software, not cruise control the car option. I've been off-track fighting with the thing on and off all day long. It was working perfectly fine until I added some new branch projects, and now it's a nightmare. I get "error reading log.xml" errors all over the place. It's like the log files were overwriting each other or something.
I think I found a possible culprit; there might have been a spare cruise control process hanging around. It's a possibility at least. I killed it, verified that nothing had an open file in the cc directory (it's tough to id those cruise control processes) with a nifty little shell script, and now I'm trying again. If this doesn't work, I think I'm gonna have to call it a night. Which sucks, because this was not what I was supposed to be tackling tonight; I wanted to get the new builds deploying to staging...:-(
I know the cc interface is cool and all, but is the setup time worth the effort? Not that I question continuous integration, but I'm questioning this product. I wonder if any of the other tools are any easier to setup.
I'm having similar problems with cruisecontrol.net (yes, I'm using .net, let's keep that low). But I'm wrestling with the setup (and the fact that I'm using .net, but that's a separate topic).
Also, now that you've had it installed for a few months now: what do you think (either the product or CI in general)? Are people using the cc interface? Have developers adapted, changed habits? Is life new and wonderful thanks to continuous integration and cc?
Actually, I don't even think the interface is that cool anymore. :-) It saved me from having to write some stuff that is boring and repetitive for projects, but it certainly hasn't been trouble free.
There's also a known bug that's pretty much a showstopper; it won't work with CVS branches. That's been out there for months now and no release. So I have to manually update the file with the bug and recompile cruise control if I want it fixed. That's pretty weak.
As for adoption, I don't know yet. It's taken so much tinkering around to get it going that we really haven't adopted it full bore. Very soon we will.
All in all, it's pretty frustrating. If we keep using it, I'll probably end up contributing to the thing to try and help it get better quicker.
What I'd really like to see is an asyncronous callback mechanism. So that as part of a build, it would could auto-deploy the web app, then run a bunch of tests against it, and then get the results back and include them on the build page. I don't want it synchronous, because auto-deploys tend to be so fragile and take a while. So I want the build to finish, report it's success/failure, then run a heavier battery of tests on it but have the results included on the same page.
So you're saying you have tests now? That's pretty sweet.
This is Rob Meyer's weblog, a weblog focused on software development and system administration based on 10 years of experience. Want to explore further? You can find out more me or see the rest of my website.
Wondering if I've written on something in particular? Try searching:
You might want to take a look at some of the more requested postings (as judged by incoming traffic):
Want more? Subscribe to this site 
or contact me at rob at big dis dot com.
See my writings on: