Integrate Early and Often

August 25, 2011 · 2 comments

A story, use case, or requirement is not done until it is integrated into the rest of the build system. “Well, it works on my machine,” is not a statement we want to hear on an Agile project. A story that is not integrated into the build is not complete and worth zero story points because it may hide significant risk.

When code is not integrated into the build it can hide the worst kind of bugs that only show up when it interacts with the rest of the system. On waterfall projects we do not get to integrate our code until the end of a project, right before we plan to ship—the worst possible time. These projects turn into an “all or nothing” situation and one tiny bug can keep us for shipping anything.

On Agile projects we eliminate risk every time we integrate our code into the build so we minimize the amount of risk we have as we go as we progress through a project. This is why we want a fast and uncomplicated build process, so developers will integrate often. How often? I usually say we should tell developers to integrate their code at least once a day but this is a bit of a trick.

Usually, the last person to integrate their code at the end of the day finds bugs in their code and because they can’t leave while the build is broken they have to stay late to fix it. After doing this a few times developers quickly realize that the sooner they integrate the fewer problems they encounter and so they end up integrating several times a day.

This means we find bugs almost immediately after we write them while the code is still fresh in our minds. Because the time between cause and effect is short we begin to change how we write our code and start adopting better practices. This is one of the main benefits of continuous integration, it shortening the time between writing a bug and finding it.

{ 2 comments… read them below or add one }

David Koontz October 10, 2011 at 1:54 pm

I’m quite amazed at the number of people who believe they do CI (continuous integration) and define continuous as every few months – when you make them define integration first and use the real meaning.

Do we need a CI – certification program :^{)}


davidbernstein October 12, 2011 at 10:40 am

David, thank you for the comment, I so agree! I see many teams that say they are Agile and do Scrum, and they do a great job of building stories in sprints, but where they fall down is in integration. Sometimes its “occasional integration”, as you say, other times it turns out they only integrate into their own branch and don’t integrate their branch into the rest of the project until right before their ship date where they get lots of “surprises” and things don’t work as expected.

There’s really no reason not to do real continuous integration from the start of a project. It is the least costly of all the Agile practices, both from the time and money perspective, yet it probably has the biggest benefit for most projects. It creates the infrastructure for many of the other Scrum and XP developer practices and a context for developers to do the “right thing” rather than throwing their code “over the wall”. As you can see from my posts I am pretty emphatic about doing it.

The importance of continuous integration and the key practices around doing it correctly is one of the five core practices in the 3-day technical training which forms the cornerstone of the Certified Scrum Developer program so there really is a Scrum certification for it. If someone has their CSD it is expected they learned the basics of continuous integration.



Leave a Comment

Previous post:

Next post: