Continuous Integration with CruiseControl.net
I am going to talk to you about continuous integration; some people prefer the term continuous build. I will not be going into depth about integrating entire systems but will concentrate on the integration of individual classes and assemblies that make up one distinct application.
CruiseControl.net is the application which I will be discussing in particular. At its most basic it can be used simply to create automatic builds which can at least prove that the application will compile on a development server and not just on the developer's own desktop.
Setting up continuous integration for a project does take some time and effort but the end result is that you can be much more lazy: just let the automated process do it all for you.
So why would you want to to implement continuous integration in the first place? Well, it eliminates many of the concerns regarding integrating code that has been created by individual developers and then has to be integrated into the final application. By building the application on a clean machine any missing files or dependencies will be instantly recognised as these will cause the build to fail. Continuous integration need not stop at just building the software it can also automate unit testing (e.g. Nunit), code coverage (e.g. Ncover) which indicates the amount of code that is actually being tested by unit test, documentation (e.g. Sandcastle) and standards compliance (e.g. fxCop) amongst others.
Now you can begin to see the real value of this automation. Developers can feel much more assured that the code they check into source control will build and, provided that it has adequate code coverage, that it doesn't break any other code in the process.
I must point out that this process does not test the display of the GUI, it only tests the functionality. As such it cannot replace all manual testing but it does cover a great deal.
CruiseControl.net
TeamCity by JetBrains is great for large scale projects where you need the ability to allow many teams to modify the configuration of the Build engine. However, as this is an introduction to continuous integration, I have chosen to use CruiseControl.net, it is free and easy to use.
The Web Dashboard is an ASP.NET application running on IIS. It provides you with details about all your builds including reports and stats on individual builds. See screen grab below:
Here is an example of a unit testing stats page:
Here is a build report:
N.B. Names of servers, UNC paths and URLs have been disguised throughout this article for reasons of security. Likewise the paths in the example files are fictional.
Cruisecontrol Tray
CruiseControl.net comes with a client side application which is shown in the sys tray and can be viewed via a double click on the icon:
Here is the application:
OK, in this window you will see four separate builds. The bottom three builds have been created for just one application. I will discuss these three as they are the most interesting.
SSE Main Build this simply builds the application in its entirety. It runs every 30 seconds looking for any new code that has been checked into source control.
SSE-NightlyBuild creates a version of the application that is the latest build which can be run on the server itself. It also performs all unit tests. This runs at 1am every day.
SSE-Documentation simply creates all the documentation from the comments.xml files created when each assembly is built. This relies on the developer adequately commenting their code using Xml comments and predefined tags preceding any method or property.
You can choose to view as many builds as you wish and they do not have to be on the same CruiseControl.net server. To do this select Settings by right clicking on the CCTray icon:
Now you can add a CruiseControl.net server and any builds it has that you wish to monitor.
If any or all of the builds are currently building, the icon changes colour to orange. When a build is complete the icon is either green for successful or red when there has been an error. The same colour keys are used in the Cctray window itself.
CruiseControl.net is the application which I will be discussing in particular. At its most basic it can be used simply to create automatic builds which can at least prove that the application will compile on a development server and not just on the developer's own desktop.
Setting up continuous integration for a project does take some time and effort but the end result is that you can be much more lazy: just let the automated process do it all for you.
So why would you want to to implement continuous integration in the first place? Well, it eliminates many of the concerns regarding integrating code that has been created by individual developers and then has to be integrated into the final application. By building the application on a clean machine any missing files or dependencies will be instantly recognised as these will cause the build to fail. Continuous integration need not stop at just building the software it can also automate unit testing (e.g. Nunit), code coverage (e.g. Ncover) which indicates the amount of code that is actually being tested by unit test, documentation (e.g. Sandcastle) and standards compliance (e.g. fxCop) amongst others.
Now you can begin to see the real value of this automation. Developers can feel much more assured that the code they check into source control will build and, provided that it has adequate code coverage, that it doesn't break any other code in the process.
I must point out that this process does not test the display of the GUI, it only tests the functionality. As such it cannot replace all manual testing but it does cover a great deal.
CruiseControl.net
TeamCity by JetBrains is great for large scale projects where you need the ability to allow many teams to modify the configuration of the Build engine. However, as this is an introduction to continuous integration, I have chosen to use CruiseControl.net, it is free and easy to use.
The Web Dashboard is an ASP.NET application running on IIS. It provides you with details about all your builds including reports and stats on individual builds. See screen grab below:
Here is an example of a unit testing stats page:
Here is a build report:
N.B. Names of servers, UNC paths and URLs have been disguised throughout this article for reasons of security. Likewise the paths in the example files are fictional.
Cruisecontrol Tray
CruiseControl.net comes with a client side application which is shown in the sys tray and can be viewed via a double click on the icon:
Here is the application:
OK, in this window you will see four separate builds. The bottom three builds have been created for just one application. I will discuss these three as they are the most interesting.
SSE Main Build this simply builds the application in its entirety. It runs every 30 seconds looking for any new code that has been checked into source control.
SSE-NightlyBuild creates a version of the application that is the latest build which can be run on the server itself. It also performs all unit tests. This runs at 1am every day.
SSE-Documentation simply creates all the documentation from the comments.xml files created when each assembly is built. This relies on the developer adequately commenting their code using Xml comments and predefined tags preceding any method or property.
You can choose to view as many builds as you wish and they do not have to be on the same CruiseControl.net server. To do this select Settings by right clicking on the CCTray icon:
Now you can add a CruiseControl.net server and any builds it has that you wish to monitor.
If any or all of the builds are currently building, the icon changes colour to orange. When a build is complete the icon is either green for successful or red when there has been an error. The same colour keys are used in the Cctray window itself.
Comments