Johnny Halife’s Blog

Fellows, I’m more than pleased to announce that our first open source project has been published on Google Code: http://code.google.com/p/sdctasks/. This project is a set of comprehensive MSBuild tasks that we built along with the maturity of our build process.

These are that tasks the conforms our internal build process. The SDC tasks are a collection of MSBuild tasks that we designed to make our development team life easy. You can use these tasks in your own MSBuild projects, use them standalone or use them as further reference to write your own tasks.

There are 8 tasks included in this library and the number continuously grow , in the v1 there are tasks for: Add copyright headers to your files, run MSTests, generate code coverage reports from your MSTests , run Source Analysis, update your assemblies information, remove duplicated files from a file collection, generate SFX packages, and enable web application code coverage for MSTests.

The deliverable is released on Source Code form, we’re looking forward to provide an installer soon!

thanks,
~johnny

On February 16th, Matías and I participated as speakers on the Microsoft Agile Architecture Forum 2008, held at Microsoft Argentina. The conference covered lots of interesting agile stuff: TDD, FDD/Crystal, the MoQ Framework and Continuous Integration/Build Automation among others.

Continuous Integration was the topic selected by us, here you can find the deck we’ve used.

In this photo: Juan Gabardini, Martin Salias, Matias Woloski, Gabriel Paradelo, Juan E. Ladetto, Johnny G. Halife, Nicolas Paez, Matias Bonaventura

Useful links about Continuous Integration

• http://www.martinfowler.com/articles/continuousIntegration.html
• http://en.wikipedia.org/wiki/Continuous_integration
• http://en.wikipedia.org/wiki/CruiseControl.NET
• Rob Conery » Source Control and Continuous Integration On The Cheap
• How To- Set Up a Continuous Integration Build in Visual Studio
• MSBuild with Cruise Control .NET
• Being Mark Cohen » Cruise Control .net with Subversion

Thanks to Martín Salías and Ezequiel Glinsky for letting us participate in this event.

thanks,
~johnny

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