I’ve been reading through my Ruby books and came across Rake. Rake is a Ruby build program similar to NAnt or MSBuild but instead of writing XML, you use Ruby instead. Now that opens all sorts of doors, so I thought I’d see if I could get Rake to build a .NET solution and take it from there.
First things first, if you want to do this you will need to download and install Ruby, luckily for us, Rake is included. You will need to reboot after to ensure your PATH is updated.
Now we are ready to rumble. First thing I wanted to try was just compiling a solution – nice and simple. There were a few samples around the interweb, and I soon created the following:
Save this file as “rakefile.rb” and put it in a folder called “build” which is at the same level as the “src” folder. Then at a command prompt, navigate to the build folder and use the following command:
Inside the Rake file we define the default build task as the :all task that is inside our build namespace. This task currently consists of one task :compile. The :compile task searches the src folder for any solution files and the builds them using MSBuild in release.
That was pretty easy and worked without a hitch. So next, I wanted to list the things I wanted my new build script to do:
- Get the current SVN revision number
- Update all AssemblyInfo.cs files with a new version number that contains this SVN rev number
- Build the solution (as above)
- Run NUnit tests
- Create test coverage report
- Copy all the files that need to be deployed (excluding those that don’t)
- Zip up these files into a deployment package
- Integrate as much as possible with TeamCity
- Should be able to run the same build script locally as well as with TeamCity
It took a little but I got it working. You can see the full file here. Below is a breakdown of each section:
Getting the current SVN revision number
First off, you’ll need to get the SVN command line client downloaded and installed. You will need to reboot after to ensure your PATH is updated.
I decided to add a new :init task that should clean up, create folders and get the SVN HEAD revision number. So here is the new code I’ve added:
There are a bunch of new constants and I’ve included the an xml parser at the top. Then I’ve added a new task called :init and added it to the :all task before the :compile task.
Inside the :init task we create some folders, then we use the SVN command line tool to request the HEAD revision information from the repository url and save it as xml to the output folder that is inside our build folder.
Once there, we can read the details from this xml file and create a version number for our application.
Updating AssemblyInfo.cs with new version number
Now that we have the SVN revision number and have generated a version number for the current build we need to apply it to our assemblies. We do that by rewriting the AssemblyInfo.cs file for each assembly in our solution. That calls for a new task:
This is pretty straightforward, we search for all the AssemblyInfo.cs files and then loop through them overwriting them as we go with a new set of attributes. We’ve defined a couple of new constants at the top to use, but the important thing is the use of the newly generated version number.
We add this new :writeAssemblyInfo task to the :all build task before we compile to ensure that every build will include the correct revision number.
Run NUnit Tests
Now we have built our solution, we need to run the tests. Here we need to do something a bit extra as we want to use the TeamCity NUint runner if it is TeamCity running the build. Otherwise we want to use the normal NUnit console for when we are running the build locally.
In this task we first get a list of all the test assemblies based on our naming convention (they end in .Tests.dll) and make sure we exclude any from the obj folders. Then if the TeamCity NUnit runner environment variable is available we use that to run the tests, otherwise, use the NUnit console program that we store in a tools folder. At present we are excluding out WatiN acceptance tests, but more on this later.
Using the TeamCity NUnit runner is important to us as it will ensure that the TeamCity test UI and data are updated correctly.
Create test coverage report
This is where it gets interesting for me. Adding test coverage reports is a good way to ensure that you (or someone else) hasn’t been lazy and written some code without a test first. I don’t think that you should have a fixed percentage that must be covered, be pragmatic.
This is a pretty short task. First we use NCover to profile the code while it’s tests are run, then we use NCover Explorer to generate a nice html report. We’ve stored these two programs in our tools folder so you don’t need them installed and it’s easier to get the build running.
You need to do a few extra things in TeamCity to get this to work and show up on a new tab. Here’s what you need to do:
- Ensure that the build agent service is logged in as an administrator. Otherwise NCover will not be able to profile the tests and you’ll see the error “Profiler connection not established” in your build log.
- Add the html report that NCover Explorer generates to your TeamCity artifacts under a folder called Reports.
- Edit the TeamCity main-config.xml file as shown here to add a tab for your html report.
Create a deployment package
The last thing that I want my Rake build to do is to collect together the files I need to deploy and zip them up for me.
As this is a Castle MonoRail application, I start this new :package task by copying all the required web files to an artifacts folder that is inside the output folder we created earlier. This ensures that we only have the files required to run the application and we exclude all other files.
Once the files are copied I noticed that because we were copying folders, the hidden .svn folders were being copied too. The only way I could see was to then delete these folders from the artifacts folder. This is where the delete_svn_folders function comes in. It just loops through and deletes any path that ends with either .svn or _svn as either can be used.
The final thing is to zip these files up. I use the 7zip command line tool to do this and I’ve added this to the tools folder again to make it as easy as possible to run the build. The zip file is saved to the output folder and is named with the project name and version number.
That’s it really, you can see the full build file here at Google Code. There are some extra bits and pieces in this build like coping the files to the development server, requesting an installer page on the site that will install the database and populate it with data but that was a bit specific for our needs so I didn’t add it here.
The advantage I can see here using Rake over NAnt or MSBuild is that you can program your build using code rather than xml which I find a lot easier and a lot more powerful.
The one thing that is missing from the build is the ability to run our acceptance tests that are written using WatiN. I found this post on Stack Overflow and this post on JetBrains forum which may point me in the right direction.
I hope that has helped, Rake is the future…