Open Source.NET

Raking in the Rewards of Codified Build Scripts: Albacore

Build scripts are finally being treated as first-class development citizens, thanks to tools like psake, FAKE, and Rake + Albacore. Ian Davis explores the Ruby-based, open source Albacore DSL.

Borne out of the frustration of markup build scripts, a movement is underway (and has been for about a couple years now) to treat build scripts as first-class development citizens. The premise of the movement is that your build scripts should be coded, not configured, to be treated as production code that is clean, refactored, easy to maintain, easy to debug, and easy to write.

The core issue with how build scripts have progressed is the reliance on markup and build runners. We as developers have disempowered ourselves through the use of MAKE, NMAKE, Ant, NAnt, MSBuild and other tools. That is not to say that they were not useful -- quite the contrary in fact -- but to continue using them is a disservice to the innovation and hard work that drives our industry and profession.

There are a few front runners in the coded build script arena for .NET developers: psake (PowerShell), FAKE (F#), and Rake + Albacore (Ruby/IronRuby). Each of these build automation tools creates a Domain Specific Language (DSL) on top of the core programming language in which they are written. The DSL gives developers incredible power to control builds with real code, while at the same time reducing complexity by providing a grammar conducive to creating builds easily.

Enter Albacore: Dolphin-Safe Rake Tasks For .NET Systems
Albacore is a DSL built upon Ruby/IronRuby and Rake, providing a build system specific to .NET developers. Rake is a Ruby build utility that executes Ruby build scripts. Albacore provides a set of tasks covering most of what we do in our build scripts for .NET projects (build, test, analyze, deploy). Here is a small subset of the tasks built into Albacore:

  • MSBuild
  • AssemblyInfo creation
  • C# Compiler (CSC)
  • MSPec
  • MSTest
  • NUnit
  • XUnit
  • Zip file creation

You can find a getting started guide on the Albacore project wiki. But the steps to get started, even if you have never used a flavor of Ruby, are very simple. First we need to make sure that we have the required gems (packages) to run our scripts. We use the Gem tool which is a lot like NuGet. From the command line:

gem install rake
gem install albacore

Once Rake and Albacore are installed, you are ready to start writing your build script. Using Visual Studio, or your favorite editor, create a file called rakefile.rb and put it in your source root folder. A rakefile is just a Ruby script, but by convention, Rake will only look for scripts with specific names. Given a solution with two projects: VendingMachine, and VendingMachine.Tests, we can create a build script very quickly to build our solution and run our tests:

require "albacore"

task :default => [:build,:test] # run build, then test
desc "Build primary solution"
msbuild :build do |msb|         # create a msbuild task named build :configuration => :Debug
    msb.targets :Clean, :Build
    msb.solution = "VendingMachine.sln"
desc "Run unit tests"
mstest :test do |mstest|        # create a mstest task named test
    mstest.command = "C:/Program Files (x86)/Microsoft Visual Studio 10.0/Common7/IDE/mstest.exe"
    mstest.assemblies "./VendingMachine.Tests/bin/Debug/VendingMachine.Tests.dll"

With this script in place and assuming Ruby/IronRuby is in your path, we can execute Rake from the command line:

rake test
rake build

By adding test or build, we can specify which tasks we wish to have executed instead of the default. You can integrate your scripts into your continuous build and watch the exit code of the rake command to determine success.

If you have the IronRuby tools for Visual Studio installed, you will get code coloring when working on the scripts in Visual Studio and you can add your rakefile to the solution items group for quick editing.

[Click on image for larger view.]
Figure 1.

Albacore does not need to be the only tool you leverage. As shown in the example, MSBuild is leveraged to compile our solution instead of directly using CSC. You can migrate what makes sense in your build system and reap the benefits of being able to do anything you want in your build. You are using the raw programming language with a nice DSL sprinkled on top. Anything you want to accomplish can be done either by extending Albacore with new task types or by directly writing the code inline. You are no longer bound to what can be done using markup

Check out the Albacore project site and wiki. There are samples and a lot of information available to get you started quickly in upgrading your build scripts. If you have a new task that others could leverage, fork the project and submit a pull request; contributions are very welcome.

NAnt: http://nant.sourceforge.NET/

About the Author

Ian Davis is the Master Code Ninja for software architecture and development consulting firm IntelliTechture. A C# MVP, Davis is an expert on the .NET Tramework and co-organizer of the Spokane .NET User Group who frequently speaks at industry events. He spends most of his free time as an open source author and advocate, publishing and working on many open source projects.

comments powered by Disqus


Subscribe on YouTube