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.