Getting Started: How often should you check in?

Yesterday my team was talking about how often the CruiseControl.Net build ran each day. The question arose, how often should we check in? For example, our team of four developers creates about 20 successful builds in a full day of coding and I think that sounds all right. I can't imagine there being a definitive answer, but you should strive to check in every time you hit a stopping point , and come to a stopping point as often as you can. Much of the point of doing Continuous Integration is to get more feedback from the system and work in smaller steps. Stopping to do a full check in dance (update from the trunk, run the NAnt script with tests) is a way to verify that your code can be integrated into the trunk with everyone else's new code. Doing frequent check in's can keep those nasty merge problems away.

Some tasks are going to tear up the code for longer periods of time. If you've got stale code because of one of these Herculean tasks, update your code from the trunk as often as possible to reduce the risk and burden of merging later. Frequently run the entire suite of unit tests as you work if you're making changes that might ripple out into other areas of the code.

The key concept for me in all software development activities is rapid feedback, reducing the cycle between doing something and verifying that something. Frequent check in's ala Continuous Integration are definitely in line with that philosophy.

I'm going to assume that we all agree that checking in code that doesn't compile or pass its unit tests is a bad thing. Broken Windows and all that stuff. The unit tests don't provide much value if you ignore them or don't run them.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.

My team checks in constantly. We have 3 and 4 builds per hour during the day, but our builds only take about 4-5 minutes, so it fast enough that we can do that. As long as you have builds that happen fairly quickly, constantly checking stuff in works well. Its those semi-long builds (like 20 minutes or more, depending on what all is in your build. For me, thats a long build. I know of teams who have builds that take a few hours) where it can get cumbersome. Then you’re left with either waiting or setting up a scheduled build. I’ve never ran into the situation where my builds took so long that it became a problem, so constantly checking in code has always been the best plan so that we get constant feedback. I hate the thought of a nightly scheduled build. I’d lay awake all night wondering what the report was going to say in the morning from an entire days work.