Managing Product Development

I’m a big fan of continuous integration. For me, that means that as developers implement small pieces, they check in the changes, verify the changes with a local build and smoke test, promote the code to the mainline, check again, and they’re done.

I’ve been having a long discussion with one of my clients about what continuous integration is. They say that when the developer is done with a particular feature, and checks that feature in, they are doing continuous integration. But it can take months for a developer to finish a feature. For me, this is staged integration.

Their staged integration is marginally better than big-bang integration (integrating everything at the end), but it takes too long for me. I want to be as close as possible to “real” continuous integration (check everything in every day). Why? Because developers don’t write that much code on a given day, and they receive feedback on what they wrote immediately. If a developers has had a bad developer day, I want the developer to know that as early as possible.

During a recent project management workshop, one of the participants tried to prove to me that his team’s version of staged integration was the only alternative. Well, if I’m not jet-lagged, I can argue with anyone at any time :-) He decided to try some real continuous integration, checking in work every day. I haven’t yet heard from him, and I suspect their lack of smoke tests and automated system tests will make their problems more visible earlier–which won’t look like success to him, but does to me.

Do you have any good words around continuous integration and why it works for you? I’d like to be able to write more coherently about it, and right now I’m limited to:

• Continuous integration provides early feedback to developers.
• The PM can see every day if the build is broken. (I use this as a predictive metric.)
• There’s less to check in every day, so it’s easier to see where the problems that broke the build occurred.
• It’s much more obvious earlier whether we have enough tests to know if the build is any good.

Let me know if you have more good ideas about selling continuous integration.

Update, May 3, 2006: Martin Fowler has updated his Continuous Integration” article.

Tweet This Post

Eric Sink is writing a series on source control how-tos (also known as software configuration management). If you’re a project manager or functional manager and you don’t know enough about source control, read them. Heck, even if you do know about SCM, read them. Yes, Eric works for a vendor, so his examples are vendor-specific. It doesn’t matter. I don’t know his tool and still understood the examples. BTW, when I teach project management, I introduce SCM as the technical piece of the project that can save your project from complete disaster.

Here’s what I think you need to know as a PM: branching, labeling, and the ability to use a multi-level checkin scheme, so you don’t break the builds but can make progress concurrently in different parts of the project. The more you know, the better, but knowing how to do these has helped me take reasonable risks to move projects forward.

Tweet This Post