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