The Changing Definition of Continuous Integration

As we wrap up every CITCON, we’re asked about what we take away. For me, a revelation was that the definition of Continuous Integration has changed wildly. Traditionally, Martin Fowler’s CI paper has been the benchmark. His current definition is:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. – Fowler 2006.

Continuous Integration has traditionally been discussed as a development practice. Unlike past CITCON events I’ve attended, we never really attempted to define CI. However, the conference was light on discussions of developer behavior. Despite being dominated by build engineers and developers, the conference focused on deployment and testing practices (particularly automated testing).

When we discussed what CI tools are supposed to do, we included deploying to QA servers to help the team get rapid feedback from manual testers about the quality of the build. We explored systems good enough at evaluating build quality to automatically release them into production. Through all this, the assumption was that this was in the domain of continuous integration tools.

CI may still be a development practice, but the crowd deemed continuous integration tools to have far broader goals. What gives?

I think we saw two major trends play out in the CI space over the past seven or eight years. The first is that the goal to rapidly determine the quality of our build led teams to pull in additional information sources. Teams wanted to extend testing from the compile, to unit testing, to static analysis, to smoke testing, to regression testing, to performance testing, to stress testing, and even try to include manual test results. And they added each processes one by one into their CI systems. As this happened, most teams wanted to break away from activities that are traditionally close to development and to those that happen later in the application lifecycle.

The second trend is that early adopters of continuous integration tools benefited from the automation features the tools provided. They looked at other tasks similar automation could help with like deploying applications, restarting servers, and even releasing to production. They then integrated those processes into their CI systems.

Continuous integration slowly stopped being focused on continuously integrating code, and more about integrating the work done by our development, test and release teams.

The CI development practice is great. So is automation throughout the application lifecycle. They aren’t the same thing, but today they have the same name. When someone on your team suggests adopting CI, ask them what they mean. If they’re leaving out either the development process of frequent integration of code or organizational integration through automation, work with them to figure out everything your team can benefit from.

From http://www.anthillpro.com/blogs