Cruisecontrol.net

Cruisecontrol.net has a webinterface. Something like this:



But how does it work?
1. The CruiseControl.NET Server is started, and a project is started according to a Project Configuration Block in the Server's Configuration
2. CCNet checks the source code repository for modifications that have occurred since the last build attempt.
3. When modifications are detected

a. CCNet labels the project with CCNETUNVERIFIEDxxx (xxx = date/time) (Visual Source Safe only, optionally)

b. CCNet gets the latest version of the source from the source control repository

c. CCNet starts the build by executing the tasks in the section of the ccnet.config file. In this example, the build will execute the task to run the NAnt build file.

4. NAnt processes the build script specified by the element . The following steps make up one possible scenario.

a. NAnt runs VS.NET using either the task or the task. The task provides better reporting capability for later steps.

b. NAnt runs NUnit using the task or the task

c.NAnt runs FxCop using the task

5. CCNet receives the outcome of the NAnt execution (Success/Failed)

a. If the build was successful, CCNet replaces the CCNETUNVERIFIEDxxx label with the next sequential build number. (VSS only)

b. The XML output files are gathered from each step using the File Merge Task and output as an xml file in the log directory specified in the element.

6. CCNet sends out email based on the elements in ccnet.config (Optional).

a. If is set, then the individuals will only receive email if the status of the build changes (Success -> Fail, or Fail -> Success)

b. If is set, then the individuals will receive email for every build.

7. CCTray displays current status of the build in the client system tray. The user can use the "Launch web page" menu item to browse to the build status website.
8. Project Dashboard enables multiple continuous integration projects to be viewed.

In short the process is like:

Where do we begin?

The first question that came in mind is "Where do I begin?". My tasks were:

1. Set up a build automation system.
2. Run builds when changes were made to the project.
3. Send notification to developers about build status.
4. Run tests.

What to choose?
My priority was to use opensource build automation system. But I evaluated comercial ones too. Why opensource, when I can use any comercial program? Well, the freedom to make changes and contribute to the community give satisfaction at the end of the day, firstly I have ability to fine tune the code to my specification and secondly I can share my views with other users and make it better. I came across CruiseControl.net by thoughtworks. ".net" because it supports net.framework.
The software I was to test is written in Microsoft's C++.

"...talking about C++, I have had many problems with it. It's like a monster, but does the job prefectly..."

What do I need?
1. Cruisecontrol.net - The mother
2. NAnt - for creating the build file

Software testing

Software testing is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service under test, with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding software bugs.

Build Automation

Build automation is the act of scripting or automating a wide variety of tasks that a software developer will do in their day-to-day activities including things like:

1. Compiling computer source code into binary code
2. Packaging binary code
3. Running tests
4. Deployment to production systems
5. Creating documentation and or release notes

This automated build is in contrast to a manual build process where a person has to perform multiple, often tedious and error prone tasks. The goal of this automation is to create a one-step process for turning source code into a working system. This is done to save time and to reduce errors.

Continuous Integration

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.