Last week I spent a lot of time working with people that I’d never worked with before.  Surprisingly, of the eleven people in the class, only about half had worked with any kind of continuous integration before.  Top off the situation with the fact that the group was not at all proficient with the style of development (TDD and DDD for example) and you end up with an interest first week for a team.

We really only worked with a full CI environment for a couple of those days, but I noticed one really interesting thing.  We never broke the build in over 30 source control check-ins.  I had even gone so far to bring in a build hat for the lucky bugger that I thought would inevitably break it.  The disappointment was unbelievable for me.

What this did do, was get me thinking about the reasons that this could happen with such a green team in such a green environment while my team at work can’t string together more than 4 or 5 successful builds before we fail.  I spent some time talking with JP about it and we came to the consensus that there was only one reason for the training team’s success.  Consistency.

Every time someone wanted to perform a check-in they first (U)pdated, (A)dded, (T)est and then (C)ommitted.  As a result of always following UATC, all code integration issues were identified well before the build server kicked off it’s process.  On top of that, the fact that the build server had a very short delay (5 seconds) between check-in and build kickoff, a very fast build and CCTray it meant that we had immediate knowledge of changes coming down the pipe.

Compared to my CI experience at work (which is beyond the end of the bad end of the spectrum), this was a great experience.  By the end of the first day I could feel the group getting some serious rhythm.  Keyboards clicked, conversation buzzed and sweet code was made.  This week I’m going to be working to see if I can get the same to happen at work.