2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – 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
- August 12, 2020
- Integrate Continuously
Perhaps the most important yet easiest to implement of all the software development practices in Agile is continuous integration. Continuous integration is simply creating an infrastructure where the code that is being built can immediately be integrated into a project.
One of the biggest challenges when writing software is the dependency relationship between the code that’s been built and the rest of the code in the system. Sometimes these dependencies are not at all obvious and only show up when we begin to integrate code from multiple developers into the entire project.
In traditional waterfall development, the software is integrated as one of the final steps of the process but by doing so it obscures many of the potential defects and we often end up in “integration hell” that delays projects and compromises code quality.
However, this can all be avoided through continuous integration. Defects are found while they are still fresh in the mind of the developers who wrote them so that they are easier to fix and they don’t get compounded by other defects through the development process.
A feature is not considered done until it runs and passes all tests on the build server. Just getting a feature to run on the developer’s machine who wrote it can hide a lot of problems that are not uncovered until integration. Integrating early and often is the cure for this. The sooner we can identify and fix defects the cheaper it is to do so.
But something magical happens when developers use continuous integration, it changes the way they approach problems. We can immediately see if our standards are not strong enough or if our approach is not the right approach for the problem by integrating our code with the rest of the system as it is being built. It teaches us in the only way that we really learn which is with immediate feedback.
As a result, the team just naturally flows to building high-quality software for the project and there are far fewer surprises at the end of the project. Continuous integration is easy to implement. Most of the tools needed to make it work are free and relatively painless to set up. Despite this, I’m always surprised to find that many development shops do not use continuous integration, even the ones that called themselves Agile.
Continuous integration also creates the technical infrastructure for other Agile practices, such as running a suite of unit tests and incrementally building features. I do not think it’s possible to have an Agile project without continuous integration and if you do, no other technical practices then I highly recommend continuous integration as the first and foremost Agile technical practice you start with. You will be reducing the risk of your project failing and be able to measure progress much more accurately when the features that are being built get fully integrated into the system, as they are built.
Previous Post: « The Importance of Technical Practices (Again)
Next Post: Drive to Testability »