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
- April 4, 2018
- Integrate Continuously
As an Agile technical consultant, people often ask me how to get the most value from their Agile technical practices. My answer is often the same, which is start with continuous integration.
Continuous integration is at the heart of all Agile software development. I see continuous integration as the defining characteristic of Agile software development, which I believe they summed up most clearly in the Agile Manifesto’s first principle, which states “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” I advocate continuous delivery and automating the validation of software because manual processes that do these things can become exorbitantly expensive.
The way quality assurance works in most organizations is fundamentally flawed, in my opinion. Don’t get me wrong, I am a huge quality advocate and I also believe that if I’m a developer I should be responsible for finding and fixing the defects that I write. Often, with a separate quality assurance organization, the developers throw code “over the wall” and ultimately become less responsible for that code. They have moved on and having to go back into code they have written previously to fix defects is majorly inefficient.
The majority of the time that developers spend responding to quality assurance issues has to do with familiarizing themselves with code that they had forgotten about. If only there was a way for the quality assurance team to constantly monitor the code and whenever there was any change whatsoever to any of the code they would be able to immediately run all of the relevant tests to prove that the new code and the existing code still work as expected. Of course, a quality assurance organization that fast and that responsive would be very expensive. Or would it?
I understand if what I’m describing is difficult to grasp but this is exactly what we get when we have a good continuous integration system that relies on a solid foundation of automated unit tests. With continuous integration, suddenly the things that were the most painful and time-consuming activities, like finding and fixing bugs, nearly goes away completely because the suite of fast regression tests in a continuous integration system can instantly find defects so the developer can fix them at the moment they’re introduced and move on quickly. This is like having a safety net under a high wire act and working with existing code is definitely like walking on a high wire at times.
Sadly, the way most software is written today, code intertwined in such a way that is very difficult to add a feature to an existing system without breaking other parts of the system. When we use continuous integration and build good automated unit tests for regression, we end up building functionally independent pieces that are not just independently verifiable but are not interwind to the rest of the system. This means our code is fundamentally more extensible and that is one of the most valuable benefits of continuous integration.
Previous Post: « Playing Dumb isn’t Agile
Next Post: The WIP Whip »