Dave Donaldson

One of the big "gotchas" for developers who are new to a Continuous Integration environment is the frequency of checking-in and checking-out code. I find that those developers still have the old habit of getting the latest version of source code when they get into the office in the morning, and then checking-in whatever they worked on *for the entire day* when they leave.

For developers living The CI Way (TM) such practice is almost blasphemy, but I think this mode of operating is still as pervasive as it is primarily because of two things:

1. Old habits die hard, and change is just plain hard.
2. Developers tend to think of a work day as an atomic unit of work.

Change is certainly hard, but it's even harder when it's actually a change to the way you think, which is really what this is all about. A developer goes from knowing he checks-in/checks-out code once a day to being told to check-in code as soon as a piece of code is functional and won't break the build. It's a bit of a shift in thought and can sometimes cause an adjustment period, depending on how well the developer can free his mind.

The kicker is that a developer's atomic unit of work is not an 8 hour work day. No, no, no. It's much, much more fine-grained than that. It's really about small blocks of code that you know not only compiles on your machine but also on the build server. The code doesn't have to be functionally ready from a requirements perspective, but should do *something* and hopefully have some unit tests to go along with it.

So how often should you check-in/check-out code? For me, I've sort of developed an internal clock that goes off in my head about every hour, sometimes a little less, sometimes a little more. But I've been living The CI Way (TM) for about 3 years now, so your mileage may vary. Just know that it should be a few times a day, whatever time interval that turns out to be.

I'll grant that change is hard, but developers have to deal with never-ending change all the time. The old adage that change is the only constant certainly applies to our profession. And as such, change should be embraced so that the practice of checking-in/checking-out code only once a day dies an ugly, horrible death.