A Continuous Integration Story

Blogger: Kirk Knoernschild

Continuous Integration (CI) is the practice of integrating and building a software product as often as is feasibly possible. CI was popularized by Extreme Programming (XP), a few years ago, but can be traced to the practices of Microsoft and other companies as far back as the mid-90’s. Since that time, CI tools and best practices have evolved to the point where implementing a rich CI strategy should be on the roadmap for any software development team. Unfortunately, not all teams choose to practice CI.

Recently, I encountered an interesting situation that clearly illustrates the value of CI. Two software teams were each working on separate software modules. Eventually, these teams knew they’d need to integrate the two modules into a larger whole. Unfortunately, communication wasn’t that great between the two teams, and while they each had a rich suite of unit tests (they created test stubs when testing the integration points between each other), and regularly tested their individual components, they didn’t ever integrate them and test them together. Finally, the day came (late in the project, mind you), when the two teams needed to integrate. In fact, integration even went fairly well. Since each team had been using test stubs that exposed the other module’s API, the act of integration went fairly well, and the two modules were able to communicate with each other without many problems. Unfortunately, things fell apart fairly quickly after that, as integration testing revealed something alarming. A major piece of functionality was missing. Each team thought the other was providing that behavior.

The moral of the story, of course, is that had these separate teams been focused on integrating their two components early and often, this problem would have been discovered much earlier in the development lifecycle. But working in silos is easy and integration is hard. Creating a false sense of progress by avoiding integration until late in the lifecycle can jeopardize the project. With CI, your product isn’t just “done”, it’s “shippable”.

Comments

[David Bressler]

Kirk,

Well said. The challenge of course is not just with integration, but performance testing, compliance with corporate standards, security, etc...

The point being that when testing for "whatever," the longer you wait, the more you have to redesign when you run into an unexpected problem, or, as in your case, oversight.

Test early, often, and not just at checkpoints between artificial boundaries (like between dev and test, or test and production).

David