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
| 17913 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

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

[quote=setya]

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

 [/quote]

 Setya,

TestComplete is a commercial tool from AutomatedQA. We used it for functional testing of a web application. It suuports many third party controls and many development tools as well. Take a look at their web site.  I am not very faliliar about XForm, so no ideas there. 

Meera Subbarao

David Sills replied on Tue, 2008/12/30 - 7:44pm

Setya:

Don't give up on Selenium quite so quickly. Have you tried creating your tests and exporting them to Java? Then you can use IE: I have found it very effective in our current application, where the government mandates the use of IE (still version 6, if you can believe it). I don't believe that an ActiveX control would have an effect here, since what Selenium does is limited to clicking on links and waiting for and checking results. I'm not sure it would care whether the results were those of an ActiveX control, which might in any case have a JavaScript interface and be amenable to a Selenium extension. I have an article coming out soon on Selenium and Section 508 that might help (two reasonably significant extension examples), but another devoted to converting a Selenium test to a Java JUnit test might be useful as well; I'd be happy to start putting something together if you think it might be helpful.

David Sills

 

Setya Djajadinata replied on Wed, 2008/12/31 - 9:32am in response to: David Sills

Hi,

Thanks for you encouragement on Selenium, from your description I must admit that I don't know well enough about this cool testing framework. But still I don't quite understand about what you mean by 'creating tests and exporting them to Java', since we do create Selenium tests in TestNG so there's no need to export.

I can't wait to read your article.

Thanks and Regards,

Setya

 

Eddy Jhon replied on Wed, 2009/03/25 - 6:23am in response to: Jeroen Wenting

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.

Comment viewing options

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