Agile Zone is brought to you in partnership with:

Meera has posted 70 posts at DZone. You can read more from them at their website. View Full User Profile

The Three Pillars of Continuous Integration

12.15.2008
| 17987 views |
  • submit to reddit

Continuous Integration commonly known as CI is a process that consists of continuously compiling, testing, inspecting, and deploying source code. In any typical CI environment, this means running a new build every time code changes within a version control repository.

 Martin Fowler describes CI as:

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 to detect integration errors as quickly as possible.

Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

While CI is actually a process, the term Continuous Integration often is associated with three important tools in particular. As shown in the image the three pillars of CI are:

 1. A version control repository like Subversion, or CVS.

 2. A CI Server such as Hudson, or Cruise Control

 3. An automated build process like Ant or Nant

So, let’s look at each of these in detail:

Version Control Repository:

Version control repositories also known as SCM (source code management) play a crucial role in any software development environment. They also play a very important role for a successful CI process. The SCM is a central place for the team to store every needed artifact for the project. It is mandatory for the teams to put everything needed for a successful build into this repository. This includes the build scripts, property files, database scripts, all the libraries required to build the software and so on.

The CI Server:

For CI to function properly, we also need to have an automated process that monitors a version control repository and runs a build when any changes are detected. There are several CI servers available, both open source and commercial. Most of them are similar in their basic configuration and monitor a particular version control repository and run builds when any changes are detected.

Some of the most commonly used open source CI servers are; Cruise Control, Continuum, and Hudson. Hudson is particularly interesting because of its ease of configuration and compelling plug-ins, which makes integration with test and static analysis tools much easier.

Automated Build:

The process of CI is about building software often, which is accomplished through the use of a build. A sturdy build strategy is by far the most important aspect of a successful CI process. In the absence of a solid build that does more than compile your code, CI withers. With automated builds, teams can reliably perform (in an automated fashion) otherwise manual tasks like compilation, testing, and even more interesting things like software inspection and deployment.

Now that we have seen the important tools in our CI process, let’s see how a typical CI scenario looks like for a developer:

  • CI server is configured to poll the version control repository continuously for changes.
  • Developer commits code to the repository.
  • CI server detects this change, and retrieves the latest code from the repository.
  • This causes the CI server to invoke the build script with the given targets and options.
  • If configured, CI Server will send out an e-mail to the specified recipients when a certain important event occurs.
  • The CI server continues to poll for changes.

Why is CI Important?

This is one of the most frequently asked questions, and here are a few points to note about this powerful technique:

  • Building software often greatly increases the likelihood that you will spot defects early, when they still are relatively manageable.
  • Extends defect visibility.
  • CI ensures that you have production ready software at every change.
  • CI also ensures that you have reduced the risk of integration issues by building software at every change.
  • CI server can also be configured to run continuous inspection which can assist the development team in finding potential bugs, bad programming practice, automatically check coding standards, and also provide valuable feedback on the quality of code being written.

Over the past several months, I have assisted several companies in implementing CI. There was a little bit of resistance from the developers in the early stages when we implemented continuous feedback. But, never heard a single negative comment about this approach. If you already have a version control repository and automated builds, you are very close to the CI process.

Download one of the open source CI servers, configure and setup a simple project. It should take less than an hour if you have automated build scripts. Start adding additional features like code inspections, generating reports, metrics, documentation and so on. Most important, send continuous feedback to your team.

Give this process a try, you sure will be surprised to see how effective it is. And, as always share your thoughts, concerns or questions. 

 

Published at DZone with permission of its author, Meera Subbarao.

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

Comments

Jeroen Wenting replied on Mon, 2008/12/15 - 2:10am

you're missing pillar #4, automated testing (and possibly code coverage analysis).

JUnit, NUnit, or equivalent. Integrate with the CI server.

Gian Franco Casula replied on Mon, 2008/12/15 - 4:18am

Hi Meera,

I agree, CI is definitely a good practice.

What do you think about 'CI ensures that you have production ready software at every change.' I think this is certainly true from a 'technical' perspective, but there is always the acceptation test (before production) that can be supported, but not replaced by CI.

 Maybe it should be 'CI ensures that you have acceptation-test ready software at every change.' :-)

 Greetings,

 Gian

Jeroen Wenting replied on Mon, 2008/12/15 - 7:11am

CI ensures you have a compiling sourcebase at every change (or at least know where the problems lie) is about the only thing you can claim about it...

It doesn't enforce correctness of the business logic, it doesn't ensure your non-compiled sources are even syntactically correct (unless you have some plugin into your CI system to test them).
Automated test harnesses can help in that, but can't provide full certainty either.

Gian Franco Casula replied on Mon, 2008/12/15 - 8:09am

I wouldn't limit it only to 'ensuring a compiling sourcebase', that would be to restrictive.

CI can't provide for testing the business logic part, but if used properly it gives insight, amongst other things, in integration errors, code quality, measurements (performance), etc.

The main points are of course the immediate feedback for all these things, reduced risk, a reproducible process. A CI server and the plugins that go with it are 'just' the tools, the concepts behind it are the driving force.

Russel Winder replied on Mon, 2008/12/15 - 8:34am

I think the image and blurb need a bit of an update:

Version control should surely emphasize Bazaar, Mercurial and Git which in all cases are superior to CVS and Subversion.

Build should surely emphasize Gradle and Gant rather than Ant and Nant :-)

Jeroen Wenting replied on Mon, 2008/12/15 - 8:54am

except of course that hardly anyone uses those tools and (in part as a result) their integration with each other and tools people do use is poor to nonexistent.

Russel Winder replied on Mon, 2008/12/15 - 9:18am

Jeroen,

I think you need to take a reality check:  to try and claim "hardly anyone uses" Bazaar, Mercurial or Git indicates a serious lack of observation of the real world.  Moreover they all have plugins for Eclipse, IntelliJ IDEA and NetBeans, so even people incapable of using a command line have access to the tools.

Oh and Gant and Gradle have plugins for Hudson.  So whilst it may be true that there are currently fewer users of these systems than Ant or Maven, the tools do exist and they are not poor.

 

 

Meera Subbarao replied on Mon, 2008/12/15 - 6:11pm in response to: Jeroen Wenting

[quote=jwenting]

you're missing pillar #4, automated testing (and possibly code coverage analysis).

JUnit, NUnit, or equivalent. Integrate with the CI server.

[/quote]

The three I have covered are basics which are required to get CI up and running. Once you have these, then there is continuous feedback, testing, coverage so on and so forth.

Meera Subbarao

Meera Subbarao replied on Mon, 2008/12/15 - 6:14pm in response to: Russel Winder

[quote=russel_winder]

I think the image and blurb need a bit of an update:

Version control should surely emphasize Bazaar, Mercurial and Git which in all cases are superior to CVS and Subversion.

Build should surely emphasize Gradle and Gant rather than Ant and Nant :-)

[/quote]

There is no doubt there are many more SCM's, build tools and CI Servers. I just gave two examples for each one of them. I have worked with many more SCM's, build tools and CI Servers than what are mentioend there. 

Meera Subbarao

Meera Subbarao replied on Mon, 2008/12/15 - 6:20pm in response to: Jeroen Wenting

[quote=jwenting]

It doesn't enforce correctness of the business logic, it doesn't ensure your non-compiled sources are even syntactically correct (unless you have some plugin into your CI system to test them).
Automated test harnesses can help in that, but can't provide full certainty either.

[/quote]

I am not sure I understand even a single line there. We have had unit tests, integration tests, functional tests running as part of the CI process. We also had metrics, and continuous feedback, and so on..

Meera Subbarao

James Selvakumar replied on Mon, 2008/12/15 - 8:32pm

Excellent article Meera.

 We use hudson + subversion + ant for our development and I would say that having a CI server definitely improves the chances of a software with better quality.

I'm surprised on seeing so many negative comments here. Yes, CI cannot guarantee you an excellent software when you have a crappy design, so what? We must understand that CI is just a process to make your development better and your "trunk" stable.

Meera Subbarao replied on Mon, 2008/12/15 - 8:45pm in response to: James Selvakumar

[quote=sskjames]

I'm surprised on seeing so many negative comments here. Yes, CI cannot guarantee you an excellent software when you have a crappy design, so what? We must understand that CI is just a process to make your development better and your "trunk" stable.

[/quote]

Very well said, James. I have been doing this for the past several months at various clients, and have seen how successful CI is becoming.The clients are surely seeing the worth of CI as well.

Developers who don't undertsand the value of CI are sure to comment negatively. No surprises there.

Meera Subbarao

Jeroen Wenting replied on Tue, 2008/12/16 - 1:28am

I don't think the criticism stems from not understanding the value of CI but rather of understanding that CI isn't the end-all and be-all of a good development process.
Whenever someone suggests that X is all you need to achieve perfection, I (and many others) get wary and start looking for arguments to debunk that claim.

While you didn't openly make such claims, the general tone of the article went a long way towards suggesting it.
Thus the discussion about what the actual benefits are when it comes to ensuring the correctness of the generated build at all levels, which is a valid one.
A CI system will happily generate a distribution archive or installer for distribution to users that contains a system that is fundamentally broken, as long as the tooling it calls doesn't generate error messages (and even if that tooling does generate errors, it's usually possible to set the CI system to ignore them).

Yes, these systems have value and can work as part of a build system, but they're no Holy Grail. That's all we were trying to mention, giving arguments as to why such is the case.

Russel Winder replied on Tue, 2008/12/16 - 2:49am in response to: Jeroen Wenting

[quote=jwenting]

Yes, these systems have value and can work as part of a build system, but they're no Holy Grail. That's all we were trying to mention, giving arguments as to why such is the case.

[/quote]

This is the crucial point, and one I fully agree with.  Competant and good programmers know the value of CI and use it effectively and well.  No amount of pushing CI (or any other "Silver Bullet" for that matter) on bad programmers will help them climb out of the morass of their lives.  Sadly.

Gian Franco Casula replied on Tue, 2008/12/16 - 3:34am

I agree it's no "silver bullet"...good code quality is "95% perspiration"...but CI is one of the things I definitely would consider mandatory in a professional software development environment.

Do you know about CITCON? it's an open space CI conference held all over the world. The last one was in Amsterdam. Very interesting to attend...Paul Duvall has been or might be one of the attendees in one of those CITCONs too.

Cyril Ronseaux replied on Tue, 2008/12/16 - 4:10am

well let's just say that CI prevent breaking software to go in production unnoticed, by warning you AS EARLY AS possible, so you have time to react and fix :)

While it doesn't guaranty against stupidity, bad work, and bad design, it DOES greatly help produce working applications.

Jeroen Wenting replied on Tue, 2008/12/16 - 5:19am in response to: Cyril Ronseaux

[quote=cronseaux]

well let's just say that CI prevent breaking software to go in production unnoticed, by warning you AS EARLY AS possible, so you have time to react and fix :)

[/quote]

Only if it breaks due to something the compilers (and, if you're smart enough to integrate them, the unit tests) catch.
If it breaks because you mistakenly remove a library that's needed at runtime but not compile time, in part of the application that (for whatever reason) is not covered by tests (say internal to a 3rd party framework that's bypassed by mocking it up for unit testing) that's not caught and your CI will deliver a flawed deployment archive.
If you blindly rely on CI and think that anything it churns out is by definition correct, you're now caught.

Meera Subbarao replied on Tue, 2008/12/16 - 9:10am in response to: Jeroen Wenting

[quote=jwenting]


If it breaks because you mistakenly remove a library that's needed at runtime but not compile time, in part of the application that (for whatever reason) is not covered by tests (say internal to a 3rd party framework that's bypassed by mocking it up for unit testing) that's not caught and your CI will deliver a flawed deployment archive.
If you blindly rely on CI and think that anything it churns out is by definition correct, you're now caught.

[/quote]

You are just talking about unit tests here, there are more tests than just the unit tests. And when you are running those tests as part of your CI, you will have to deploy your application and it will definitelt fail. 

 It looks liks you need to know a whole lot more of what CI does than can be written in this comment or article. I suggest you read the book "Continuous Integration: Improving Software Quality and Reducing Risk". 

Meera Subbarao

Paul Davis replied on Tue, 2008/12/16 - 4:53pm

Forgot the forth pillar, automated testing

Guess I should have read the comments before posting  :-)

 

I know it's not needed to have CI up and running but, it is needed to give value to CI.

Anyway, good post

Meera Subbarao replied on Tue, 2008/12/16 - 9:51pm in response to: Paul Davis

[quote=willcode4beer]

Anyway, good post

[/quote]

Thanks Paul.

Meera Subbarao

Jeroen Wenting replied on Wed, 2008/12/17 - 6:00am

I do know quite a bit about what CI does, but I've never yet seen a CI environment that deployed and ran integration tests on an application (let alone run functional tests).

 Might be possible, but would also make the build cycle rather long which somewhat defeats the purpose.

Meera Subbarao replied on Wed, 2008/12/17 - 9:21am in response to: Jeroen Wenting

[quote=jwenting]

I do know quite a bit about what CI does, but I've never yet seen a CI environment that deployed and ran integration tests on an application (let alone run functional tests).

 Might be possible, but would also make the build cycle rather long which somewhat defeats the purpose.

[/quote]

Yes we do run all the tests. And there are many variations on how you run  these tests as well. My suggestion would be to read the book I mentioned above. Every single doubt of your will be cleared.

Meera Subbarao

Gian Franco Casula replied on Thu, 2008/12/18 - 1:18am

Hi Meera,

Paul Duvall, the author of the book, has written an excellent series of articles about CI.

Here is a link to one of them: http://www-128.ibm.com/developerworks/java/library/j-ap09056/index.html

Greetings,

Gian

p.s. I love your posts, keep it up :-)

Meera Subbarao replied on Thu, 2008/12/18 - 10:12am in response to: Gian Franco Casula

[quote=gianfranco]Paul Duvall, the author of the book, has written an excellent series of articles about CI.

 

[/quote]

Gian,

Thanks. I know Paul Duvall very well, he was my CTO and  now a close friend. I have read all those series. Thanks for sharing this with JL.

Meera Subbarao

Meera Subbarao replied on Thu, 2008/12/18 - 10:12am in response to: Gian Franco Casula

[quote=gianfranco]Paul Duvall, the author of the book, has written an excellent series of articles about CI.

 

[/quote]

Gian,

Thanks. I know Paul Duvall very well, he was my CTO and  now a close friend. I have read all those series. Thanks for sharing this with JL.

Meera Subbarao

Gian Franco Casula replied on Thu, 2008/12/18 - 10:49am in response to: Meera Subbarao

Hi Meera,

I suspected you must have read them...the link was in fact intended for the skeptics and the curious on JL.

...another pro that knows his share in this area is John F. Smart (I've read your review) I had the chance to attend a presentation of his in Belgium last week...incredibly interesting.

Kind regards,

Gian

 

David Sills replied on Sat, 2008/12/20 - 11:54am

All:

I can speak with authority on Meera, having known her very well for many years now. Believe me, she understands that continuous integration involves deploying and testing the application, at least on a recurring basis.

There is nothing magical about testing; it is just as possible to create an application that doesn't properly function with testing as without. Tests are software, too, and must be treated with as much care as the application proper.

Meera knows this and respects it in her work. When she says, "This causes the CI server to invoke the build script with the given targets and options," the "given targets and options" in her mind doubtless includes regularly deploying and testing the application.

As to the tools recommended, whether one tool or another, the first key is to get the process right. Unfortunately, not too many environments really accomplish this. If yours does, rejoice! You're among the lucky (or incredibly competent) few. You are now in a position to consider what tools are right for what you need. If not, however much time you spend to get this part of your development skills honed will be more than suitably rewarded.

David Sills

Setya Djajadinata replied on Wed, 2008/12/24 - 10:24pm

Hi Meera,

Firstly, thanks for good articles.

While I was reading the book I realized that automation is the absolute requirement to get involved in CI, I mean if you can not automate the process than it's impossible to include the process in CI.

Regarding automated testing whether it's unit, system or integration testing, the choice of technologies/frameworks highly determine your ability to perform automated testing, some frameworks are inherently more automatic-testable than others.

For example in my current project in which I'm assigned as outsourced programmer we're forced to use legacy UI web technology that's not automated-testing friendly. I would like to hear your experience on this kind of situation.

Thanks.

 

Meera Subbarao replied on Tue, 2008/12/30 - 9:28am in response to: Setya Djajadinata

[quote=setya]

For example in my current project in which I'm assigned as outsourced programmer we're forced to use legacy UI web technology that's not automated-testing friendly. I would like to hear your experience on this kind of situation.

 

[/quote]

Setya, have you tried using tools like Selenium or TestComplete? There are many more available, but I am mentioning just these two since I have used them for automating and running web applications for legacy systems. And also integrated them with nightly builds.

Meera Subbarao

Setya Djajadinata replied on Tue, 2008/12/30 - 10:11am in response to: Meera Subbarao

Meera,

I know Selenium and have tried it so I can tell that it won't be useful in my case.

The legacy framework I was talking about was XForm based technology that requires ActiveX component to be installed on the browser side (IE only) and you know when you use this kind of technology you're at the mercy of the vendor to provide testability which is not in my case.

No, I haven't tried TestComplete yet. How does it work compared to Selenium or Rational Robot ?

Regards,

Setya

Comment viewing options

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