Atlassian Giveaway Winners!
• Julian Simpson
Thanks to everyone who wrote a story for the Atlassian Giveaway. The entries are in, the judging is complete, and here's the results!
First prize goes to John Martin, who wrote a story of despair and hope around Continuous Integration. John's an Atlassian user already, with two other products, so he's happy to make the hat trick with a Bamboo license.
I wish I had two more licenses to give away to Wolfplusplus and Daniel Spiewak. They both had great stories. Martin Scholl had an amazing tale of folly from a telco firm who should have known better.
I wish I had a special prize for Patrick Debois, who came up with this inspired entry.
Tshirts go to the guys above and: Graeme Gillies, Chris Melikian, Andy Yates, Neil Tingley, and two readers who had to remain anonymous. I'll be asking for your addresses to hand on for fulfilment. Huge thanks to the Atlassian crew for sponsoring this giveaway. I know they'd be grateful if you took a few minutes to see what they are doing with Bamboo and the rest of the developer tools that they sell.
Here's John's winning entry:
I think my best experience with continuous integration had nothing to do with integration _testing_. When I joined the project as the cm/build guy, they were in a cycle of work real hard for two weeks then give the stuff to the build guy to build on Thursday evening. It had to be Thursday because all day Friday and sometimes the weekend would be spent trying to get the thing to actually compile. Typical stuff: developers checked in 'simple' changes without compiling and testing, they didn't always update to get the others' stuff, they forgot to add new files to source control, they worked in windows and our server was linux, maven dependencies hadn't been added to our local site, etc. Tracking these down and running around from developer to developer was time consuming. And then the deployment to test could take another half day because something would be wrong with the way the EAR was generated and it wouldn't load into test's weblogic server. And, of course, to be honest it wasn't always the developers' fault -- sometimes we didn't make a necessary change to the server or upgrade java or whatever.
We introduced cruisecontrol simply to run a compile on every checkin, and within a month, official test builds were smoother because compile problems appeared immediately upon check in _and_ we knew who to talk to without all the hassle of layering everybody's changes in at 5pm on Thursday. By the time we did the official build, we hardly ever saw a compile problem again. Then we added automatic weblogic deployment (locally), just to prove the EAR loaded, and we could build and deliver to test almost immediately upon code freeze.
That particular project never got to the point where it was using the continuous build for any real test coverage. Two years later, the new build guy asked me why they should still bother doing the cruisecontrol thing if it wasn't testing. He hadn't seen an error in a year. I told him that testing should really be added, but even so, if he took away his continuous build, he was going to have to learn a little more about reading stack traces.