Agile Zone is brought to you in partnership with:

Leaving university, I thought I'd be a developer happily knocking out code but was always drawn to tech support. How do we help people use our tools better? Now, I mostly specialize in consulting and introducing new customers to our tools. I am a Tech Evangelist and Lead Consultant at Urbancode. Eric is a DZone MVB and is not an employee of DZone and has posted 79 posts at DZone. You can read more from them at their website. View Full User Profile

The Changing Definition of Continuous Integration

04.28.2009
| 7924 views |
  • submit to reddit
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

Published at DZone with permission of Eric Minick, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Fabrizio Giudici replied on Tue, 2009/04/28 - 7:35am

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.

Definitely agree. See e.g. the plugins for Hudson that provide support for generating a release in a controlled environment, just pushing a button. Maybe we should start calling it CLM (Continuous Lifecycle Management)?

replied on Tue, 2009/04/28 - 3:18pm

Apropos CI check out the new SE-radio podcast on the topic with Chris Read: http://se-radio.net/podcast/2009-04/episode-133-continuous-integration-chris-read

Eric Minick replied on Wed, 2009/04/29 - 10:00am

Continuous Lifecycle Management? Not too shabby. We've floated things like End-to-End CI and Application Lifecycle Automation. That darn "Continuous Integration" term keeps sticking around, and I think we're about ready to give up on trying to call it anything else. You really do need to ask people what they mean though.

The neat thing at the conference was that as it got underway and attendees were suggesting topics to cover, you could tell that pushing CI down the lifecycle was really becoming normal, or at least a normal goal.

What a relief. The first question on the AnthillPro mailing list from 2003 was about reproducible deployments. It's been a long time getting to this point, but I think the industry is there (or almost there).

john green green replied on Fri, 2009/11/27 - 12:05pm

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.
nike china shoes

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.