Continuous Integration in a nutshell

Last week Matías and I were working on automating the builds of our projects. We didn’t want just to automated the building process, we also wanted to implement Continuous Integration. Throughout this post, I’ll share the experience we’ve had since we started.

Which product to use?

We started with Microsoft Visual Studio Team Foundation Server, since it’s our configuration management platform. We did research over the build services that come out-of-the-box and a little bit of spiking extending those services using the API.
Our first spike consisted in creating a WebService that subscribes to TFS Check-In Event. We didn’t have so much luck with this, since for each project you’ve to configure a bunch of things, handling those build projects is not straightforward. We were a little bit dissapointed, we wanted to take advantage of TFS integration on Visual Studio 2005.

We kept moving over the internet til we found  CC.net, this is an open-source product created by Thoughtworks, it’s an extensible automation platform were you can configure multiple things as FxCop, NUnit, NCover, among others. Also it integrates with mutiple source control providers. So we decided to give it a chance.

Trying Cruise Control.net

As an old-fashioned geek, I’ll never download a source control project in MSI project and let another geek decide where and how should I install their products. We downloaded the binary-zipped version of Cruise Control.net. We unzipped the package and started to see what’s in there. Inside the zip file we found:

  • Documentation, each released (not-live) version of CC.net includes all the documentation to be used locally.
  • Server, is the server application. This application whose responsibilities are:  listen SCC for changes, create a local workspace on the build machine, and perform the configured tasks (run FxCop, run NUnit tests, etc.). It cames in two formats, Windows Service and Console application.
  • CCTray, this is the client application for developers to check 24*7 the build health, is the desktop way to monitor your projects.
  • WebDashboard, is the web application where you can force builds, get an overall project portfolio health status, and review log files.

Now that we knew what’s in there, we started to configure CC.NET (on Longhorn Server Beta 3).

Configuring Cruise Control.net

First of all we needed a box where we can deploy it. We created a VPC with the following characteristics:

  • Windows Longhorn Server B3 (minimun installation, with IIS7 and Powershell features).
  • 1GB of RAM
  • Hosted on Virtual Server Enterprise R2

Once we had the box, we started with the CC.NET service configuration. We read this guide, for step-by-step installation, we choosed VSTS plug-in for monitoring source control, and MSBuild as the build task.

We started with just a single project, a common .net 2.0 project, it built succesfuly. So CI was running, so we said : "Ok, next step let’s monitor this". First we went for the webdashboard, deploying it on the IIS7 as it’s explained on this page. (Note for II7 users: You should change the AppPool to be .Net Classic cause the WebDashboard comes with kind-of rewritting http module, not supported by default on IIS7 configuration).

We navegated to webpage http://localhost/webdashboard, and voila! it was there. Then we decided to go for CCTray since we thought :  "Cool, I’ve got this configured but now howwe let the devs know when they brake the build". So we took a look to the CCTray application that comes out-of-the-box and it just was a plug-and-play thing, we configured it to use the WebDashboard connection mode pointed to the http://buildServer/webdashboard/ and showed up the project we had previously configured.

Up to this point we were really enthusiastic about how things were going, we went for more configuring the whole portfolio on the build server, but suddenly popped up a problem not all projects have same target platforms, same involved technologies, and we wanted each project to built just with it minimum requiriments so we avoid things like incompatibillity of technologies and we ensured (more at this point) the quality of our deliverables.

Creating the scalable and extensible Build Services model

We started the design of this infrastructe based on the following premises:

  • We wanted a single dashboard for the whole project portfolio
  • We wanted a single source for CCTray
  • We wanted to scale out adding for e.g. 3 more types of build servers or reducing the number of them with out pain, and with no need of configuring everything again.
  • We wanted mutiple build machines with different platforms and software inside them.

Researching, we found that on the dashboard.config you can tell your dashboard where are your build machines, and contact them via remoting, and also we discovered that you can have more than one application (build server) configured for your dashboard. How to modify the dashboard.config can be found here, on the CC.net documentation.

Finally in the following diagram we’re showing how was the initial CC.NET Deployment Strategy (single server) and the design we came up with.

Default Deployment

Final Deployement

thanks,
~johnny



Leave a Reply