Hudson

The CI Breakdown

To be quite honest I did not know very much about Continuous Integration (CI) until I went through the tutorial and read the article. One reason for my lack of knowledge about CI is that I have never worked on a large scale project that would require CI in order to keep the project manageable. CI can keep a project manageable by building, testing, and verifying the project often (every time the code repository changes) in order to spot issues as quickly as possible. Spotting issues right away allows for these issues to be fixed as quickly and as early as possible which makes them far easier and far more manageable to deal with.

One aspect of CI that I found to be particularly interesting is that CI is only as good as your software engineering practices. I guess in a lot of respects, it is no different than an emma or a findbugs. These tools are quite helpful but they are only helpful if you actually run them. The same is true for CI. CI is only helpful if you practice good software engineering practices like those listed below (description here)

• Avoid infrequent check-ins
• Avoid broken builds
• Avoid minimal feedback
• Avoid spam feedback
• Avoid a slow build machine
• Avoid bloated builds

If you avoid these CI anti-patterns as they are called, then CI will prove to be a truly beneficial tool for you. Overall, I think that Hudson and CI will be a vital tool for me in the future, as it can automatically check to make sure the latest commit to the repository builds successfully, and if it doesn't, immediate action can be taken to fix the problem.

Hudson and the Visual Studio Sensor

I was able to use Hudson to build the Hackystat Visual Studio Sensor project that I am currently working on. Using Ant to build C# projects is somewhat tricky and better handled through NAnt, which is not supported by Hudson. Therefore, I had to go for the command line build option that comes with Hudson. Basically what I had to do was turn the command line instance into an instance of the Visual Studio 2008 Command Line. From there I could just run "devenv %PATH%VisualStudioSensor.sln /Build" to build the system. To set up the Visual Studio 2008 Command Prompt, I copied the contents of the vsvars32.bat file (which sets up the Visual Studio 2008 Command Prompt) into a .bat file which I called buildsensor.bat. At the end of the .bat file I put the "devenv %PATH%VisualStudioSensor.sln /Build" line to build the system. Luckily Hudson defines an environment variable %WORKSPACE% which can be used to get to the files checked out of the repository.

Running the Build on the CSDL Server

In order to run the build on the CSDL server, you would have to install Visual Studio 2008 and set up the path to the buildsensor.bat file in Hudson. This seems like somewhat of a pain to do just to build the system so I am currently looking into various alternatives. One alternative is to use csc.exe which comes with the .NET framework. Basically it is a C# compiler which can be used to compile .cs files. I am not sure how how extensive the compiler is or how it compares to the "Build" command in Visual Studio, but it looks promising and would require much less space (Visual Studio requires several gigabytes). The other alternative would be to tackle C# building in Ant. There appears to be an Ant library for .NET building, but I believe it uses csc as well to build the project. Other than how to build/compile the system, the Visual Studio Sensor project can be setup relatively easily:

1. Select the "Build a free-style software project"
2. Setup the Subversion repository by linking the google code repository and providing the proper authentication
3. Select the "Poll SCM" option under "Build Triggers" and schedule it as "* * * * *" (every minute check the repository for changes)
4. Then under "Build" check the "Execute Windows batch command" option and setup the path to the buildsensor.bat file
5. Then setup the "Post-build Actions" with possible email notification