Continous Integration : Express Delivery using Cruise Control.NET & NAnt

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. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.
~ Martin Fowler ~

"A software engineering term describing a process that completely rebuilds and tests an application frequently"

in transition and getting agile

  • Integration problems are detected and fixed continuously - no last minute hiatus before release dates
  • Early warning of broken/incompatible code;
  • Immediate unit testing of all changes;
  • Constant availability of a "current" build for testing, demo, or release purposes;
  • The immediate impact of checking-in incomplete or broken code acts as an incentive to developers to learn to work more incrementally with shorter feedback cycles.
  • You catch build breaks early on.
  • In a distributed development environment where developers do not always communicate with one another, continuous integration is a great way to assure the developer that the build he or she is building is the latest one.
  • Continuous integration also causes less regression
  • The feedback loop is smaller.
  • A developer does not have to wait for the end of the day or week to find out how the check-in affected the build.
  • Integration testing moves up in the chain.
  • Every check-in goes through the integration testing where problems are caught early.
  • Continuous integration enforces better development processes.
  • Each developer is held accountable.
  • You always have a latest-and-greatest build to use in demos, showcases, etc.
Continuous Integration (CI) is a well-established practice which allows us as developers to experience fewer development conflicts and achieve rapid feedback on progress.

  • Maintenance overhead often increases.
  • Some teams find that the level of discipline required for continuous integration causes bottlenecks.
  • The immediate impact of a check-in often causes a backup because programmers cannot check in partially completed code.

Continuous integration has both advantages and disadvantages. The primary disadvantage is that it can disrupt the development process. A cost is always incurred when you are developing a component and are suddenly forced to deal with integration issues. The advantages, however, outweigh the disadvantages in this case because you can deal with integration issues while the consequences of integration decisions are still fresh in your mind. Continuous integration can also reduce schedule risk resulting from failures to identify integration issues that may cause significant rework to one or more components.

In my previous organization I remember my teams Associate Project Lead sitting late night to build the project integrating all the modules, I then didnt realize that the manual rigmarole that he was battling had a name. He would daily appear at our workplace at mid-day often half-dead due to the ordeal.

Now that ordeal has a name "Continuous integration", a software engineering term describing the process that completely rebuilds and tests an application frequently.continuous integration is accomplished via a serialized build process . At the completion of a task, the developer (or development pair) takes a build token and runs the build process, including tests. If the tests pass, the task can be committed to the source code repository and release the token. More recently a server process or daemon that monitors a version control system for changes is live and automatically runs the build process (e.g. a make script or Ant-style build script) and then runs test scripts (e.g. JUnit or NUnit). In many cases the build script not only compiles binaries but also generates documentation, website pages, statistics and distribution media.

Continuous integration is the process of generating a build whenever a programmer checks code into the source control server. When you use this process, it is a good idea to have a dedicated build server where you can synchronize and compile the sources, and run unit tests. Software development life cycle processes evolved over time. Development teams realized the importance of having periodic builds. It started with a weekly build. Then it grew tighter when "nightlies" began, and tighter still with "hourlies." As the benefits of frequent builds became more obvious, organizations wanted more builds. And now we have continuous integration. But nightlies still exist. Many organizations still count on them to get a formal, reliable build.

CruiseControl as a tool for Continous Integration is especially valuable when the team is transitioning to agile development and has a large legacy process or source code burden. In those cases, the build fails a lot, and CruiseControl is a valuable cleanup tool and also in certain kinds of heavy-duty testing. Monte-carlo simulations, some kinds of performance testing, memory leak testing, some kinds of automated regression testing. These are all legit, and can be very slow. On the down-side the full test suite is not run before developer checks in his code, so the build will break more often. Since the repository is not locked it is more likely that the team will get code that doesn't work. The test suite is likely to be slower, too, because you won't have to personally wait for the whole test suite to pass.

Commerically available options for CI
  • AnthillPro - a commercial tool from Urbancode. Along with CruiseControl, Anthill is one of the original tools in this category; it remains a market and technology leader constantly adding new features such as dependency mangement, workflow automation, etc.
  • Bamboo - Commercial continuous integration server from Atlassian
  • BuildBot - a Python/Twisted-based continuous build system
  • Build Forge - IBM Rational's adaptive framework to standardize and automate build and release processes.
  • CABIE - Continuous Automated Build and Integration Environment. Open source, written in Perl, works with CVS, Subversion and Perforce.
  • Apache Continuum - a continuous integration server supporting Apache Maven and Apache Ant.
  • CruiseControl - Java-based framework for a continuous build process.
  • CruiseControl.NET - .NET-based framework for a continuous build process.
  • CruiseControl.rb - Ruby-based framework for a continuous build process.
  • DamageControl - a continuous integration server for Ruby.
  • Electric Commander - a continuous integration server by Electric Cloud, John Ousterhout of Tcl fame's company.
  • Apache Gump - Apache's continuous integration tool.
  • Hudson - MIT licensed, written in Java, runs in servlet container, supports CVS, Subversion, Ant, Maven, and shell scripts.
  • LuntBuild - a powerful open source build automation and management tool
  • Tinderbox - a Mozilla based product
  • TeamCity - a commercial tool by JetBrains. Web-based with IDE (IntelliJ IDEA, Eclipse, Microsoft Visual Studio) support. Includes many innovative features.
Build Responsibilities

There is one responsibility that I think is worth noting above all others: it must be self sufficient. This is an absolute must, with out it chances are the practice will fail. The responsibilities listed below aren’t necessarily in order, in some situation they may not be needed. View these as a list of possible responsibilities the build server will fulfill.

  • Monitor for trigger (There are many reasons to trigger and these will depend on your objectives for you build server. The most common trigger is changes to source control.)
  • Cleanup and verify build enviroment
  • Control version of product and artifacts
  • Compile Debug configruation of product and test code
  • Run tests
  • Compile Release configuration of product code
  • Compile installer
  • Publish results and artifacts
  • Trigger dependant builds
  • Complete in about ten minutes

Developer Responsibilities

The developer responsibilities listed below are in sequence of execution, order is important. This list starts off in the greater sequence of events where the developer has just completed the task at hand and is ready to be the build submission process.

  1. Synchronize with the SC repo
  2. Compile
  3. Execute unit tests
  4. Make fixes if needed
  5. Claim the build (don’t forget to communicate if it’s a significant change)
  6. Submit changes to the SC repo
  7. Wait for the build result (do not start coding on somthing)
  8. If the build result is success congratulations, if not fix it

Work in progress !! Please come back after I finish reading all this stuff ;-) Tools for your greater CI !!
References: I Dont Like CruiseControl.html

Developer Resources & Tools :

TreeSurgeon.NET CCNETConfig NCoverExplorer NAntGUI CIFactory (SVN)
Source Control Management
Source Control HOWTO- by Eric
SubVersion Manual  -
Branching & Merging Primer  -
posted @ Tuesday, March 6, 2007 1:43 PM

Comments on this entry:

# re: Continous Integration : Express Delivery using Cruise Control.NET & NAnt

Left by giochi del casinò at 3/29/2010 1:00 AM
I am sure the same concept can be used in a varity of way to get lot of real time information.The person who create this post he is a great human..thanks for shared this with us.

Your comment:

(not displayed)


Live Comment Preview: