I have just finished reading Freakonomics. It’s a great book, but it’s gone too fast! It took me about 3 days to complete it. Also, the authors are right to indicate early on that there is no real unifying topic. Maybe a longer discussion on how they obtained those data would have been useful.
Anyway, it just happens that I read recently about Mass Observation in the New Yorker. It strikes me that the data collected by MO is exactly the kind of data that Steven Levitt would use. I wonder if he has already consider it? Or maybe the data are simply not formalized enough to be useful.
I was generally impressed by what people seems to have put in place for Continuous Integration. Here is a list, from the top of my head:
- load testing; Douglas Squirrel from youDevise told how they were using CruiseControl to trigger a (simple) load test scenario. The test environment is not perfectly representative, and the build does not get broken when it fails. However, a web page gets updated, which helps in having an idea of the *change* in performances. As an interesting twist, they are loading real time quotes from Reuters.
- functional tests: considering that they usually take a long time to run, the consensus is that it is not smart to run them along with the unit tests. The solution is to have “very frequent” build that gives quick feedback to the developers. And, on the side, have “very complete” build that does as much test as possible.
- “pipelines”: some people wanted to manage an order in the builds run by CruiseControl. ie. “run this build (client application) only after this one (framework) has been run successfully”. Apparently, some worked around this by getting the first-order build to commit a file in the version management system, which would be detected by the second build.
- Mike from Atlassian explained that they felt the need to get more metrics from their builds. They managed to put together a system that would store various information to a database, which could later be queried. This is to be released eventually as a product, codenamed Bamboo.
The Bamboo thing sounds nice, but wouldn’t it be even better to store many other data, such as the number of developers over time, the number of commits, etc.? Some data could be obtained by a tool like Bloof, others from the bug tracking system… The grand plan would be to obtain a huge wealth of information, which could then be exploited by a manager, maybe even with the help of a data analyst. And then, some tendencies would be infered by some brilliant Levitt-wannabe! I can’t wait ;-)
I have an older post on CITCON.
At CITCON, I was quite happy to see one person suggest the topic “CI and offshore”, as I am involved on an offshore project myself. Unfortunately, this person didn’t show up, and just we were just 3 in the session.
At any rate, it seems that the same old problems appear with offshore when using Continuous Integration. Basically, the distance is simply too much of a problem when trying to spread the word.
Someone from Nokia did report that he had good success in encouraging people to use CruiseControl and unit tests. But it must be said that he is not part of a particular project, so presumably he has less pressure to deliver immediate results. Though, he did have to travel extensively to get people to use and keep using CC and JUnit.
I’ve left more detailed notes on the CITCON website.
I have older posts on CITCON.
Someone at CITCON (I’m pretty sure it was Mike) had a really good idea: use the service offered by Amazon Elastic Compute Cloud (Amazon EC2) to run CruiseControl.
Basically, Amazon EC2 offers virtual machines where anything can be uploaded. No need for a physical machine anymore.
If we assume the equivalent of a machine with a 10 Gigs hard drive running 12 hours a day with 5 Gigs of daily traffic (probably vastly more than necessary), the monthly cost would be around:
10 Gigs x 0.15$ + 12 hours x 30 days x 0.10$ + 5 Gigs x 30 days x 0,2$ = 67.5$
Less than 70US$ per month! That’s what it would cost to run a full-fledged machine running CruiseControl. And it appears easy to upgrade to more instances.
This could lead to very innovative usages. For example, as a consultancy, you could setup your system remotely, and get ready as soon as you move to the client site. As a service company, you could easily scale as your customer base grows.
Of course, the main limitation I see is that most companies would be very reluctant to open their local environment to external resources…
I have an older post on CITCON.
