Integrate Early and Often
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)