2025 Public Training Schedule
June 23 26, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions Online
July 22 – 25, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions Online
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2025 To Be Agile
- August 25, 2011 ( 2 comments )
- Integrate Continuously
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 }
Previous Post: « Don’t Do (Up Front) Design
Next Post: Do You Play All or Nothing? »
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 :^{)}
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.
David.