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. 

For the past several months, we've been using a build server on our project for continuous integration.  I've been involved with teams, in the past, that used build servers, but this particular setup has proved to to be a real asset and the experience of using it day-to-day has been a pleasure. 

I'd like to share how we built the server.  I'll make several posts over the next few days to address the various parts that work together.  Along the way, I'll discuss version control (subversion in our case), Cruise Control .Net, NAnt and StatSvn.

What We're Trying to Accomplish

Why would you want a build server, anyway?  The primary benefits of a build server are continuous integration and automation.  Let's say you have a team of five and all are working on the same project.  Each has a piece of the application that they're working on.  As they develop, they test the code they're responsible for.  Who, though, is responsible for making sure that all the pieces work together?  The reality is that at any given time each developer's machine has a unique version of the application that's different everyone else's.  The purpose of the build server is to periodically take the code that exists in the source repository and process is to verify the code all works together.  In other words, the health of the code (how well all the parts integrate) is always known.

There are many functions the build server can perform.  It can do a compile, execute test suites, generate an installer or even a CD image.  Crucial to the whole process is source control, so let's look at getting started with Subversion.

Subversion

All source code repositories have their own take on how best to solve the problem of keeping up with all the changes made to to the code base.  Some require the developer to lock a file while it's being worked on, while others allow changes to be made by anyone at any time.  Subversion falls into the latter category.  Basically, a developer grabs a snapshot of the current version in the repository, makes his changes and then pushes them back up.  Committing of changes happens in a transaction so the commits are always stable.  Subversion takes the version being committed and merges it into the current version in the repository.  This means that manual merging is greatly reduced.  On the occasions when Subversion can't figure out how to merge the changes, the developer is notified and is give an opportunity to manually do the merge. 

Installation

You can obtain the subversion installer here.  I downloaded the installer, svn-1.4.6-setup.exe, and executed it taking all the defaults.  At this point, all the binaries are installed on your system, but Subversion hasn't been configured to run as a Windows Service.  To set it up to run this way, execute the following from a command line.

C:\>sc create svn binPath= "\"c:\program files\subversion\bin\svnserve.exe\" --service -r c:\repos" DisplayName= "Subversion Server" depend= Tcpip

This command will create a Windows service named "Subversion Server" that runs svnserve.exe when it's started. 

Subversion Client

Regarding a client that you'll use for interacting with your Subversion server, you'll need to decide whether you prefer to have the client integrated into Visual Studio or not.  If having everything available within the IDE is you bent, then you'll likely prefer something like AnkhSVN.  Personally, I'd rather do my source repository work outside the IDE and prefer to use TortoiseSVN which installs as a shell extension.  Either way, you'll need to create a repository and then connect to it with your client.

Creating and Configuring a Repository

On the machine on which the Subversion service is running, create a folder in which you'll be storing your code repository.  Then, go to a command line and execute the following.

svnadmin create c:\path-to-repos

This will create a repository for you in the directory you created.  Now, we need to configure access to the repository.  Go to the folder you created, before, and you'll find that three files have been created there.  First, open the svnserve file.  All the lines in the file are currently commented out.  You'll need to modify at lease three of these lines.  Find the line that contains "anon-access".  This line controls what access users connecting to the repository anonymously have.  Your options are "read", "write" and "none".  In my case, I set this value to "none".  Next, find the line that contains "auth-access" and set its value to either "read", "write" or "none".  this line controls what access authenticated users will have.  For the last change, find the line that contains "password-db" and remove the "#" character and the space that follows it to un-comment the line.  This tell  Subversion to look in the passwd file to find a list if valid users of the repository.  Save your changes to this file.

Now, open the passwd file.  All lines in this file are commented out, as well.  Beneath the line "[users]", you will need to create a list of valid users for the repository in the form "username = password".  Save your changes.

Accessing the Repository From a Client

Whichever client you choose, you'll need to specify a URL and your credentials.  URL's for subversion are of the form svn://server-name.  For credentials, you'll need to use one of the user-name / password combinations you created in the passwd file, earlier.  At this point, you should be able to check out (get a copy of the current version) and commit (check in) to and from your repository.  If, however, you're having problems reaching the server you'll want to check that the Subversion service is running and you also may need to configure svnserve.exe as an exception in windows firewall.

That's it for Subversion.  Next time, we'll set up CruiseControl.Net.