2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
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) 2024 To Be Agile
- May 15, 2019
- Integrate Continuously
I believe that continuous integration is at the very heart of Agile software development. It allows us to go fast by going small. What I mean by this is that we learn by building in small increments that it’s more straightforward to create modular software that’s independently verifiable and by building smaller it gives us the opportunity for more feedback from our build, which helps keep us on track as were creating systems.
The first principle in the agile manifesto is:
“Our highest priority is a satisfied customer through early and continuous delivery of valuable software.”
Continuous integration is the way we implement “continuous delivery of valuable software.” And I don’t believe that the original authors of the Agile Manifesto meant that all software should be delivered on a continual basis but I believe that nearly all software should be built so that it is releasable at any point.
The way we build software in the Waterfall model was that we put off integration until the end of the development cycle. We had already analyzed, designed, coded, and tested our individual modules and then they sat in a queue somewhere waiting to be integrated. When we finished integrating all the modules in the system we found the nastiest box. Integration was often a living hell for us and required long nights trying to find elusive defects that only show up when we integrate the system together.
The best way I know, the only way I know, to avoid this problem in integration is to not put it off. Instead do it, do it all the time. When our build gives us fast, reliable feedback then we can integrate every little piece as we create it and the system alerts us at the moment there’s any problems so we can fix it immediately.
This makes a huge difference in developer’s workflow because they don’t have to spend 90% of their time reacquainting themselves with problem software that they didn’t know had a problem until much later after they built it. This is the real beauty of continuous integration and I think one of the major values of Agile software development.
Scrum talks about feedback and how important it is. We get feedback from our customers. We get feedback from our Product Owners. But I think that the most valuable feedback that we get when we’re developing software is the feedback that we get from our build. When we do continuous integration and have a good suite of unit tests that automate the verification of the features that we’re building then we can confidently know our progress and know that any major defects won’t creep into the system without us being alerted.
To me, that assurance is worth its weight in gold and it comes for free when you have a trustworthy continuous integration environment.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Agile Infrastructure.
Previous Post: « One-Click Builds End-to-End
Next Post: Define Acceptance Criteria »