In this second installment in a series of posts about building a development environment I will discuss the setup of a continuous integration server.
I will not try convince you of using continuous integration in your process, or discuss the possible benifits of using it. A lot has allready been written about this. If you have decided to use continouos integration and are looking for experiences and practical advice on implementing the process, then this post can be of some help.
This post is by no means “The Way” of building a development environment. In fact, you will notice that at times I deviate from some of the practices advocated by the referred articles at the end of my articles. It’s our interpretation of the process and how we implement it. If you have any remarks or suggestions for improvement, please post a comment.
- CruiseControl.NET (version 1.0): This is run on the integration server.
- Subversion (version 1.3.1): This is the source control application and is run on the source control server for central code management and the client part is on the developer box for retrieving the code to wrk on the application.
- TortoiseSvn (version 188.8.131.5204): This is an optional but very handy tool for windows shell integration of the Subversion client.
- Nant (version 0.85 rc3): Used for automating the complete build process and runs on the integration server.
Installation of CruiseControl.NET is a no brainer: there is an installation program available at the website. Just executing it and stepping through the process installs everything you need. Mind however that we are going to use the Web Dashboard, so you might want to make sure you have Internet Information Server installed with Asp.NET.
The installation does not add the folder to the windows path environment variable, so you might want to do this yourself for easy execution of ccnet.exe.
Monitoring for integration
So, where do we monitor for integration?
Well, we monitor our Project codelines and of course our Main codeline.
The project codelines contain the adaptations for the current projects we are working on, so it’s not difficult to see why we monitor those.
The main code line is also monitored, because we eventually will integrate the code in the project codelines with that in the main code line and we would like to monitor this process. It is also possible that small changes are made directly in the Main code line.
We do not monitor the Release folder of the repository. This folder is only used to concolidate our changes, but does not contain any “evolutionary” stuff. Neither do we monitor the Extern folder because this only contains external libraries which we do not change.
Let’s get praticle
So let’s get our hands dirty and monitor any changes in our Subversion repository with CruiseControl.NET
In the first article we made an experimentation environment and a source repository. Now we will monitor our repository’s code lines with CruiseControl.NET.
In our buildsrvr folder we put a file “ccnet.config” with the configuration of our integration server. Here’s the content:
<intervalTrigger seconds=“60“ />
<intervalTrigger seconds=“60“ />
In our buildsrvr folder we also have a subfolder “buildconfig” which contains two files: helloworld1.build and helloworld2.build which are simple Nant scriptfiles that simply print a message. Their content is similar to the following:
<project name=“test“ default=“build“>
<echo>Hello World from Project1</echo>
These files get executed each time we make a change to our repository.
What is going on?
In the ccnet.config file we insert a <project> node for each codeline we want to monitor.
Which codeline gets monitored is described in the <sourcecontrol> node’s <trunkUrl> childnode.
What to do when a change is made in the monitored codeline is described in the <tasks> node. In this initial version of our configuration file we simple execute the Nant task by using the <nant> node. In this task we tell it where to find the Nant executable (<executable> node) and which build file to execute (<baseDirectory> node for the folder and <buildFile> node for the file)
Now we execute the following commandline in our buildserver’s working folder:
Make sure you start ccnet.exe in the folder where you just saved the ccnet.config file. This way, ccnet.exe will pickup this file as its configuration file.
Because this is the first time we start ccnet with this configuration, ccnet will execute our buildscripts and if everything worked fine, you should see the following in you webbrowser when you enter the url http://localhost/ccnet
You can see that our two configured projects get monitored. If you click on the project1 link you see the projects website. If you then click on the “Latest Bild” link and next on the “View Build Log” you get something like the following:
You can see that the message printed in our Nant build file is shown here (see highlighted section in the above image).
Well, that’s it for this entry. In the next part we will check in some code and organise our build process. See you then…
4 November 2006: original version
10 januari 2007: added more detail and some references.