The practice of continuous integration represents a fundamental shift in the process of building software. Integrating continuously makes integration a part of the natural rhythm of coding. Continuous integration is about progressing steadily forward by taking small steps.

Integration should happen continuously, and continuously is more often than you might think. The frequency of integration will vary from project to project, from developer to developer, and from modification to modification. However, as a goal and a good Rule Of Thumb, developers should integrate their changes once every few hours and at least once per day.

Learning how to integrate so frequently requires practice and discipline and Deciding when to integrate is all about controlling risk. The longer that developers go without integrating, the greater the likelihood of conflicts and the larger the effort required to resolve those conflicts.

A successful integration is a measure of progress. It provides feedback that the new code runs correctly in the integration environment and successfully interoperates with the rest of the code base. Code sitting unintegrated in a developer's workspace simply does not exist. It is not part of the code base, it cannot be accessed by other developers or tested by the customer. Only when it has been successfully integrated is the benefit of the new code realised.

How Cruise Control works – To achieve Continuous Integration:

CruiseControl.NET (Here after CCNet) consists of a suite of applications, but at its core is the CruiseControl.NET Server which is an automated integration server.

·Every time a developer commits a new set of modifications, the server will automatically launch an integration build to validate the changes.

·When the build is complete, the server notifies (By email) the developer whether the changes that they committed integrated successfully or not.

Lets understand by below exapmple - What steps the CruiseControl.NET server goes through when running an integration on a project built using NAnt and checked into a Visual Source Safe (VSS) Source Control Server.

Effectively, integration becomes as easy as checking in code. Using an automated integration server not only makes integration easy, it also guarantees that an integration build will happen. There is no danger of developers forgetting to validate their changes after checking in.