ericlefevre

The Conference on Continuous Integration & Testing, Asia edition, is tomorrow! I wish I could be there, but the plane ticket is unhelpfully expensive :-(

Well, I’ll have to make up by going to CITCON Amsterdam in October! Who’s joining me?

I thought it’d be interesting to look at some download statistics for Hudson and CruiseControl, probably the 2 OpenSource CI tools with the most mindshare currently.

Want to know more about CruiseControl, Hudson, and other CI tools? Meet the creators, contributers and users at the next CITCON conference in Melbourne, June 27th & 28th. Cannot make it to Melbourne? Then CITCON Amsterdam, October 3 & 4 is for you (I know I‘ll be there). Or CITCON Minneapolis, April 17 & 18, 2009.

(more…)

The North-American edition of CITCON, the conference on Continuous Integration and Testing is over. Check out the session notes on the conference wiki.

(more…)

The Conference on Continuous Integration & Testing is taking place this year in Denver (April 4 & 5), Melbourne (June 27 & 28) and Amsterdam (October 3 & 4).

(more…)

CITCON, the conference on Continuous Integration & Testing, is coming to Denver, April 4 & 5. Seats are limited (but free!) and registration has been going briskly (probably the fastest of all CITCON events). Register now!

(more…)

After doing it at AgileOpen, I again had the chance to demonstrate Hudson. The attendants had all proved their CI credentials, to say the least, as they included developers on AnthillPro, Build-o-matic, and CruiseControl, of course (how many CC developers in the room? at least 6, I’d say).
I think my point that Hudson was the easy, very usable alternative, went well, but they were more impressed with the combinations matrix feature (I personally think that the killer feature is the simpleness of the form where a job is defined).
At the evening drinks, one or two people asked whether I was part of the development team, which was flattering. I guess I should consider getting more involved, but there are already so many things I want to do, and so little time! How do all these guys do?!

I was very excited when Squirrel suggested a topic about mutation testing. I had looked at Jester & Jumble before, but gave up after a couple of hours, as they are not very easy to setup, and mostly not maintained.

The idea of those tools is to make changes to the source code (Jester) or the bytecode (Jumble), and check if the tests still pass. If they are well written, they should fail when the code is changed. If not, then the code is not covered properly. Ideally, you should only have one test failing; otherwise, it means that you have redundant tests.

Ivan, the creator of Jester, was present, but admitted that he had not even used it in years. After seeing the interest of the participants, he seems willing to give it more time. Hurray!

Check out my notes on the conference wiki.

I came back from Brussels this Sunday evening, after some visiting of the city. The conference has been a blast, especially networking with other participants. It has been great seeing again people that were there last year in London… and sometimes pick up the conversation where we had left it! I also talked with a few people that were at AgileOpen in the Netherlands last June. I can’t wait to see them all a third time in 2008.
(more…)

We now have more than 80 registrants for CITCON Brussels, more than 2 weeks before the 19th.

This year, I have volunteered to help organize registrations, so I get to see every single registration request. It’s interesting: sometimes, you don’t see anyone registering for days (oh my god, is this going to be a turkey?, then 7 people register in a single day. The general pattern, though, is that the number increase more or less regularly.

Also, about one request in six is pure spam.
We should reach the threshold for the maximum number of seats a couple of days before the event.

This year, I am going to attend the conference on Continuous Integration and Testing, in Brussels on October 19-20. The last edition I’ve been to, in London last year, was enormous fun, so I cannot wait to get there.

Join us!

This year, I am also helping in registering participants, so you’ll probably hear from me.

Paul Julius and Jeffrey Fredricks have announced CITCON D/FW 2007. It is the third in a series where CITCON London 2006 was number 2.

Considering how enjoyable CITCON London was, it is totally worth going to CITCON D/FW if you’re around.

Something to keep in mind for the future: during CITCON, Joe used a projector to display his computer while he was taking notes on the same computer. In this way, anyone who shows up would have an idea of the subject immediately discussed. It might be useful too for people attending the session, as seeing things written down might give them more time to reflect on things.

I had suggested a topic covering “Beyond Installing CruiseControl - CI Culture with Management and Developers”. It actually got merged with “Social Impact of CI”, suggested by Michael, and “How to introduce CI”, from Jeffrey. Jeffrey had, in fact, a presentation that he had already discussed in a previous conference, so most of the session ran around it.

Michael reported that he had witnessed situations where the developers distrusted their management so much that they were quite opposed to CI in general, figuring that it would be used to identify and fire people that break the build often. It could be said that the culture of blame was already there, though.

Jeffrey’s presentation argued that changing habits is extremely hard. He quoted a sociologist who wrote that “familiarity exerts a powerful force”. Essentially, people rather do something that is painful, but that they know about, rather that something better that they do not know.
To leave this vicious circle, one solution is to give small bonuses to the developers. For example, give one sticker per unit test written. The personal impact of this is important; people would probably not do it for money (which would have to be small amounts anyway), but they would do it when it makes them feel good. Douglas commented that he couldn’t imagine doing this sort of things with his team, as it would be perceived as childish (maybe giving tickets for a beer at a company party who work better?).

I think the root of the matter is that constant vigilance is paramount. Basically, it is not possible to simply tell people to write unit tests, or to install CruiseControl. Some will probably start doing so, but precious few will keep on doing for good. Those that do, however, should probably be used as relays to remind the other developers to keep on writing tests, and add new techniques and tools.

That reminds me of a study on productivity. A consultant had realized that, in a factory, productivity would go up when the light is stronger. However, he also noted that, when the light was dimmed, productivity would *also* go up! The point is that productivity increases when people feel that someone is paying attention to them. Or maybe it is the simple fact of changing something in their environment which prevented them from sinking in monotony.

Notes on the session are available on the CITCON website.

I have older posts on CITCON.

Update: quoted sociologist is Virginia Satir.

Mike from Atlassian was quite a vocal participant to CITCON. During the talk on CI Culture, he explained that the developers in his team were among the top 5%, but that they wanted to reach the top 1%. Someone then asked: “where did you get those figures from?” “I just made them up!”

Here are some other random data that could be useful:

• PJ from ThoughtWorks estimates that, from his own experience, when introducing Agile methodology in an average team, 30% will quit, because they will not want to change.

• Jeffrey reckons that unit tests must be able to run at the rate of 100 per second, otherwise people will not really use them (is that the number of classes? of test methods? of assert clauses? I guess it is still a useful rule of thumbs)

I have an older post on CITCON.

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.