Software Integration is often an exercise which is deferred until all the team members are “ready�? to integrate only to find that they are indeed “not ready�? to integrate. I remember a client who approached me and said my developers are telling me “We are just 1 week away from a successful build�? for almost 6 months.

What is Continuous Integration

Continuous Integration is a practical approach for easily managing integration and it enables teams to successfully turn out builds. How do Continuous Integration achieve this? it is quite simple , first start by integrating and publishing builds. It is one of those approaches like (Test Driven Development – write test cases before you write the code !) which sounds outrageous at first and then so cool within a few days of thrashing out the details. One side effect of having a continuous integration environment in place before you go about developing your product in a collaborative team environment is that it forces you to think about a qualified release not as the final abrupt end product of a traditional development cycle but as a artifact that builds incrementally as your project progresses. And that could mean the difference between making a release and being just 1 week away from it for almost 6 months.

References

To read the classic article about Continuous Integration by Martin Fowler please check the link http://www.martinfowler.com/articles/continuousIntegration.html.

Scheduling Build Iterations

Setting up the build schedules so as to reflect the activeness of the source code is an import step in establishing a successful CI environment. If builds are scheduled too frequently at the start of the project, developers might complain about too much nagging by a build tool, so it might be best to integrate it once every few days. As your developers become more comfortable about the build nanny you can schedule builds more frequently. You might want to make more frequent build like twice a day once your release schedule approaches. Integration testing should be an integral part of the build environment as it is important to have a code that compiles and also code that functions as documented.

Using tools to use to setup a Continuous Integration Environment

Cruise Control and Anthill provides two different tool chains but very similar strategies on achieving a continuously building environment. AntHill Pro comes with additional features for reporting and collaboration and resolution which is not part of the community edition of AntHill and is a recommended tool for those projects which involve large cross functional teams for which frequent builds are unavoidable tools that prevent total chaos.Atleast few developers initially get confused about the usefulness of a tool like cruise control or ant hill and instead try to develop proprietary build automation systems using a variety of scripting languages and ant . Few follow this approach(I did before I found Cruise Control) , the result will be a new “build project�? , the automation project which requires it’s own nanny developer and never gave enough feedback to developers to determine who created the breaks in the build .

Downloading and Setting Up Cruise Control.

Download a release of Cruise Control from http://cruisecontrol.sourceforge.net.
On windows workstations run the cruisecontrol.bat which runs the cruisecontrol web deployments inside a jetty(http://www.mortbay.org/jetty/) runtime.

Test the deployment by typing http://localhost:8080 . It will show a 404 Page Not Found but with a list of deployed contexts. Invoke http://locahost:8080/dashboard to view the Cruise Control dashboard which shows the build status. It also provides a link to the cc-config JNLP network installer which would install and launch the thick client. The cc-config java thick client provides an easy to use management tool that lets you edit the configuration files or you can use http://localhost:8080/cruisecontrol/ to review the configuration and build logs.

Cruise Control has the notion of what is called a Build Loop which essentially routinely checks for modifications in the source control system and initiates a build cycle periodically. The projects that participate in a build loop are stored in the config.xml Which is present in the root directory of the installation.

Here is how a typical config.xml will look like . Of course there can be multiple project definitions.
The project element defines the project that is being built.
The Boot strapper element lists down locations that should be updated before a build is issued. In this case we are ensuring the currentbuild.txt and the master build file is uptodate with two bootstrapper plugins.
The modification set element describes the set of files that should be checked for modification before a new build is initiated.
The schedule element specifies the schedules at which time the builds should run.
The log element specifies where the logs can be found.
The publisher element configures the listeners who are interested in build events.

Nice Article Praveen, But given a day to day scenerio I find Continous Integration is not a practical approach in many scenerios. As a Example: I work in a Software Development Company, And each of my clients environment is different. Now one of my client environment is that they use RAD7 for development and WAS6 for the server environment. Now since the project environment is IBM vendor Specific. And althought all the claims about interopertability or platform indepence we know that each J2EE application we build is tied to a particular deployment environment. Like RAD7 uses IBM JDK which is their own implementation of JAVA SDK... Tools like Cruse Control depends on opensource Build tools like ANT or Maven and it also depends on the SUN JDK... So even if I use continous Integration I cannot guranntee that my application build on non IBM platform will work fine on my clients IBM Environment. I am not targetting IBM I am just using its name as an example the same thing can happen in other environments like Weblogic, JBoss, Tomcat etc... And even as a Software Developer Company my clients environment will be different based on their choices or existing investments. What do you think about this?

Shoumik, I agree with your observation. Setting up a continuous integration environment might seem a daunting task when your solution is primarily being built and delivered once. There are lot of projects which require iterative development , most products follow an iterative development cycle. So continuous integration is for projects that span multiple build and release iterations.I would say if your solution requires an iterative development cycle, even if it is a single phase you could derive a lot of value if the project is sufficiently long. For small projects with small teams i would recommend it.