The trouble with deferred integration is that it’s very hard to predict how long it will take to do, and worse it’s very hard to see how far you are through the process. The result is that you are putting yourself into a complete blind spot right at one of tensest parts of a project – even if you’re one of the rare cases where you aren’t already late
–Martin Fowler

Continuous Integration Abstract

The larger a project and the more teams involved, the more important frequent, even continuous, integration is important. Oddly enough, integration is talked about in a way that belies its true value. We talk about “integration errors”, which implies, not intentionally, that the errors occur during integration. But, in fact, integration errors are not errors in integration at all. They are collaboration errors that went undetected until integration occurred. If we talked about code and test in the same way we’d call bugs detected during test “testing errors.” The challenge is: how do we keep diverging efforts in sync with each other so that when integration occurs, no out-of-sync errors are detected. One method, of course, is continuous integration. Continuous integration eliminates the time from the creation of out-of-sync-ness to its detection. Frequent integration is useful when continuous integration is not possible.

Details

At a minimum, different groups that are technically dependent upon each other should work on the pieces that comprise the total, so that they can be integrated on a regular basis. If teams must work with other teams where integration of code is not possible, then each group should create mocks that represent the other groups code. These mocks can be defined by tests that define the behavior expected of each other’s code.

As with all areas of software development, the delay between the occurrence of an error (in this case getting out of synch) and its detection (during integration) is a source of delay. While most developers have the experience that they spend a lot of time fixing bugs, the reality is they spend a lot of time finding the bugs. Continuous integration also allows for quick releases – clearly an essential capability for all Agile methods.

Many development organizations struggle with continuous integration and have given up trying to achieve it. However, the impediments they are having are actually the sign-posts for what they need to do to improve their code. Continuous integration is often difficult when:

Builds take a long time

Testing takes a long time – no automated testing

Fast Builds

For continuous integration to work in practice, one must be able to build code quickly. Modularization helps this, as does building code in components

Component Integration

The proper use of object-oriented methods can greatly decouple a development group’s code into modules that can allow for better testing. Testing of components can be very slow, creating integration problems due to time and cost issues. Mocks can also be used to help component integration by providing fast test-platforms as needed.

System Integration

System integration is just a larger scale of component integration and can be dealt with using the same methods. In Scaled Agile Framework, system integration often is a shared responsibility of the system team and agile teams.

Learn More

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Chapter 4. Addison-Wesley, 2011.

Shalloway, A., Bain, S., Pugh, K., & Kolsky, A. Essential Skills for the Agile Developer: A Guide to Better Programming and Design. Chapter 9. Addison-Wesley, 2011.

Last update 15 January, 2013