The Agile Success Factor: Continuous Integration

Kirk Knoernschild discusses the subtle though significant ways that continuous integration can be leveraged—from helping to align IT with the business to enforcing architectural constraints—and shows that this fundamental aspect of agility is the defining and necessary element of a truly agile development experience.

Agile has grown and evolved from a very simple developer centric process defined by Extreme Programming to a complex product brand that enterprises are using to bring more resiliency to governance programs, enterprise architecture initiatives, and application portfolio management efforts. But at its roots, there remains a key fundamental aspect that defines the essence of agility on the software development project. Continuous Integration is a strategy where software is integrated and built continuously, or at least as frequently as is feasibly possible. Many teams have adopted a continuous integration strategy, yet do not fully realize all the benefits that continuous integration might bring to the development effort. This article discusses the subtle though significant ways that continuous integration can be leveraged—from helping to align IT with the business to enforcing architectural constraints—and shows that this fundamental aspect of agility is the defining and necessary element of a truly agile development experience.

Closing the LoopAt the center of a continuous integration strategy is an automated and repeatable build. In "Activating the Lifecycle", I talked about the aspects defining a robust build process, and pointed out some of the benefits of an automated and repeatable build. But an automated and repeatable build does not guarantee that a software development team will realize the advantages of continuous integration. Having worked with numerous software teams who have setup an automated and repeatable build, I've discovered that the most successful teams use continuous integration to close the feedback loop.

For a moment, visualize the macro-software lifecycle. Traditional teams begin by analyzing the problem and gathering requirements, designing a solution, constructing the software, executing tests, and finally, deploying the completed software. Of course, iterative development aims to perform each of these steps within iterations, possibly a four to six week period. Certainly it's logical that if we perform a slice of the entire software lifecycle in less time, we'll generate important feedback that can be used to plan future iterations. This is the greatest benefit of iterative development, and most experienced development teams recognize its value. Like a traditional software lifecycle, iterations tend to go well the first few days. But as the iteration deadline approaches, the team frequently falls behind schedule, often creating a backlog of items to be addressed in subsequent iterations. Now take this notion one step further.

Continuous integration aims to perform the entire software lifecycle each time the automated and repeatable build is performed. In other words, each build represents a complete pass through the software development lifecycle. Is this possible? Is it entirely realistic to believe that a team can perform the entire lifecycle each time the software is built? Hourly? Possibly even more frequently? Doubtful. However, a sound continuous integration strategy creates the ability for a software team to perform any part of the lifecycle any time they desire or need. This very notion, the ability to perform any part of the software lifecycle at any time, is the single greatest benefit that teams practicing a successful approach to continuous integration understand. It is no surprise, then, that teams successful with continuous integration have mastered knowing when to perform software lifecycle activities to maximize the necessary feedback at the appropriate moment in time. These teams have closed the feedback loop, and left little room open for high risk, long-term, unsuspecting problems to surface.

The Right Stuff Of course, if software development was as simple as implementing a continuous integration strategy, we'd all have done it long ago. Unfortunately, while some teams find great success with continuous integration, others do not. Knowing when to perform various lifecycle activities can be amazingly difficult. As a general rule, any activity performed later in the software lifecycle that can be moved toward the beginning of a project helps you gauge your progress. Essentially, you can view continuous integration as a process pattern

Like all other patterns, there is a common underpinning that forms the foundation of continuous integration (that being the build), but the overall strategy must be tailored to fit your context (i.e., your team, your project, and your technology). Young developers learn early that simply because the application works on their machine doesn't mean that it works on other machines. Experienced continuous integration practitioners recognize that a successful build only proves that the software passes the compiler and the automated test suite, but does not mean that the application does what clients need. One oft-cited benefit of continuous integration is that teams avoid significant problems, such as compile errors, when attempting to integrate code. While true, this is only the beginning, as there are other critical activities that can dramatically improve the advantages of a successful continuous integration strategy.

Pages

About the author

Kirk Knoernschild

Kirk is software developer with a passion for building great software. He takes a keen interest in design, architecture, application development platforms, agile development, and the IT industry in general, especially as it relates to software development. His recent book, Java Application Architecture was published in 2012, and presents eighteen patterns that help you design modular software.