In continuation of the series I started last time, I'll look at the part Cruise Control .Net plays in the creation of a build server today.
All the individual parts of a build server would be of little use if they were all working alone. There needs to be some entity responsible for orchestrating the workings of and communication between the individual parts. The software we've used for this purpose is Cruise Control .Net. It's job will be to initiate a build. We can tell it we'd like a build every time a configured amount of time passes or whenever a new version of the code base has been checked into our repository.
First, you'll need to install the product on your build server. You can download the installer, here.
Execute the installer and take the defaults. In particular, on the select components page of the installation wizard, choose to install the CruiseControl.Net server, the Web Dashboard and the examples. The server component is what we'll be configuring to do the work of initiating builds, the web dashboard will allow you to check the results of each build via a web interface and the examples will help you to learn how to configure the server.
On the additional configuration page, select both to install the server as a windows service and to create a virtual directory for the web interface.
When the installer has finished, we need to configure our server. To do so, navigate to C:\Program Files\CruiseControl.NET\server and open the file ccnet.config. The file will contain this text:
<cruisecontrol>
<!-- This is your CruiseControl.NET Server Configuration file. Add your projects below! -->
<!--
<project name="MyFirstProject" />
-->
</cruisecontrol>
Our task, now, is to replace the contents of this file with XML that will tell CruiseControl when and how to perform a build. As a start, replace the file contents with this text.
<cruisecontrol>
<project name="MyProject" >
<webURL>http://servername/ccnet/</webURL>
<triggers>
<intervalTrigger seconds="60" />
</triggers>
<modificationDelaySeconds>60</modificationDelaySeconds>
<sourcecontrol type="svn">
<executable>c:\program files\subversion\bin\svn.exe</executable>
<workingDirectory>c:\build\source\ProjectName</workingDirectory>
<trunkUrl>svn://localhost/repository/path/to/project</trunkUrl>
<username>uname</username>
<password>password</password>
</sourcecontrol>
<tasks>
<nant>
<executable>c:\nant\bin\nant.exe</executable>
<baseDirectory>c:\build\source\ProjectName</baseDirectory>
<buildFile>c:\build files\Project.build</buildFile>
<targetList>
<target>TargetName</target>
</targetList>
<buildTimeoutSeconds>600</buildTimeoutSeconds>
</nant>
</tasks>
<publishers>
<xmllogger />
<statistics/>
</publishers>
</project>
</cruiseControl>
All the values in red will need to be modified to suit your specific needs and setup. Beginning at the top, you'll need to specify your own project name. Next, specify the name of your build server in the webURL. The intervalTrigger is the amount of time that CruiseControl will allow to elapse between each check for changes and indicates that you want CruiseControl to initiate a build when the code base changes (after a check in). There are other trigger types you can specify. Check the documentation for these other types.
Next, the modificationDelaySeconds is the amount of time to wait between detecting a code base change and initiating a build. This allows time for subsequent check ins to be completed before a build starts. As you can see, we have specified SVN as out source control type (CruiseControl works with several other repositories, as well). We need to tell CruiseControl where to find the svn.exe executable. Also, we need to specify a folder into which the code base can be checked out. To detect changes in the code base, CruiseControl uses a Subversion command to check for updates. This command effectively compares the local copy of the code base with the version on the Subversion server. I suggest you determine where you'd like this local version to reside, create the folder if necessary and then check the code base out into that folder. Then specify the path to that folder as the baseDirectory. trunkUrl is the path, in the repository, where the code base can be found. Next is the username and password to use when accessing the repository.
We'll skip the nant section, for now, and cover it next time. The publishers section is important because if no publishers are specified, you won't be able to see any of the results of the build in the web dashboard. The function of a publisher is to take the raw output from the various tools we'll use, capture it and format it into a format that can be viewed in the dashboard. Here we have specified the xmllogger and statistics. There are other options available. See the documentation for CruiseControl to check them out.
So, at this point, we have our source control repository and a server that detects when the source has changed. We have yet to specify what the actual build process is, however. We'll discuss that, next time, where we look at nant.
Subscribe