It can be found over at GitHub.

The idea of writing a .Net build tool in Ruby comes up from time-to-time. Most recently, that I’ve seen, Jeremy Miller briefly mentioned the idea. Now that I finally got around to setting up a weblog I thought I would share my experiences in writing such a tool.

Some History

My employer started the transition to .Net about 1.5 - 2 years ago. There were a lot of discussion about whether or not to use Team System. It was a discussion similar to the one Roy Osherove and Ayende had. In the end it was decided not to use Team System.

A downside to that decision is the number of pieces involved. Some of the different pieces that had to be managed include Subversion, NUnit, MSBuild, NCover, log4net, iBatis, internal frameworks and libraries. Everything needed to be managed as one cohesive unit. Beyond encapsulating the various development tools, there was the desire to enforce things like solution and directory layouts, namespacing, project names, unit tests, continuous integration, etc…

Stack was developed to solve the above problems.

Why Ruby?

So, why Ruby? Ruby is an excellent language for gluing things together. Stack had to bring in many disparate tools together so it was a good fit. In addition, .Net was just being introduced so there were no legacy NAnt or MsBuild scripts to contend with. There was no interest in going down that road if it could be avoided. Lastly, my feeling is, the more exposure .Net developers have to Ruby the better (or more generally, exposure to different languages is a good thing). Being introduced to Ruby through using Stack is a delicate way to do that.

Some Details

• Stack is a gem that is distributed via an internal gem server.

• All dependencies are packaged with stack. That includes all required SDK tools. You should be able to build a Stack based solution anywhere where the .Net Framework and Stack is installed.

• Stack is used to generate new solutions. There are several defined solution templates like lib, forms and shell to name a few. For every VS.Net project generated a corresponding .Test project is generated. The one exception is the View project, if there is one.
  • 

• It’s easy to retro fit Stack around an existing solution.

• Stack has the concept of version freezing. There tends to be a lot of smallish solutions that become feature complete pretty quickly and then sit untouched for one or more years. To ensure the tests and the rest of the build continue to work, each solution is frozen to a specific version of stack. The solution must be explicitly upgraded to a newer version of Stack. As a result, Stack’s toolset can be upgraded without worrying about breaking builds when a new version of Stack is released. To illustrate the point a little bit, the build server has about 5 different versions of stack installed, all being used by solutions in various stages of development.

• Stack initializes it’s environment by parsing a solution file to discover all the projects. Test projects are selected by matching a pattern, the default is project names ending in Test. Parsing the solution and project files allows stack to provide a basic set of tasks out of the box.
  • 

• Stack has an import task that creates a new Subversion repository, sets appropriate commit permissions (everything is anonymous read by default), imports the solution and does an inplace checkout. During the import process Stack also creates a new product, via a web service, on a Project Management type web app (written in Rails).

• Build output is written to both STDOUT and a HTML report when build tasks (compile, test, coverage, etc..) are run locally.
  • 

• Stack has a cruise task for easy integration with CriuseControl.rb. If stack detects that its being run as a CruiseControl.rb build it redirects output to the appropriate location.

In Summary

That is stack in a nutshell. It’s used on a daily basis to manage 100+ Visual Studio solutions and counting.

With RSpec, examples tend to get broken up into several describe blocks. As a result I almost always create a helper module that gets included into the describe blocks.

Assuming a Post model, post_spec.rb might start out looking like the following:

require File.dirname(__FILE__) + '/../spec_helper.rb'
 
module PostSpecHelpers
  def default_attributes
    { :title => 'Ninjas Kick Ass',
       :body => 'Ninjas are dangerous, watch out!' }
  end
end
 
describe Post do
  include PostSpecHelpers
end
 
describe Post, 'validating' do
  include PostSpecHelpers
 
  it "should require a title" do
    post = Post.create default_attributes.merge(:title => nil)
    post.should have(1).error_on(:title)
  end
end

There is not a whole lot to DRY there. The common pattern shown is to create the object while overriding one or more attribute defaults. The tediousness of the code is pretty minor but it starts to grow old. Another thing that bothers me is RSpec knows a model is being spec’d. That seems like useful information that should be taken advantage of.

Normally I would just deal with the above. You usually want to tread carefully when abstracting things out of specs.

I did end up coming up with something. What put me over the edge was the need to create and new up models in shared specs.

For example, what if there is a Post and a WikiPage that both have a title and body? You could do inheritance but I tend not to like that. You never know how the two models will diverge. Instead I usually create a module with the shared code. I’ll then write specs that are shared by both taking advantage of it_should_behave_like.

The result of what I ended up with is very simple. Just a couple of helper methods to create (and new up) models while taking advantage of the fact that RSpec knows modles are being spec’d.

Here is the example above rewritten:

it "should require a title" do
  create_with(:title => nil).should have(1).error_on(:title)
end

Here is what I have in spec_helper.rb:

module ModelExtensions
  def new_model(overrides = {})
    self.class.described_type.new(respond_to?(:default_attributes) ? 
      default_attributes.merge(overrides) : overrides)
  end
  alias new_with new_model
 
  def create_model(overrides = {})
    self.class.described_type.create(respond_to?(:default_attributes) ? 
      default_attributes.merge(overrides) : overrides)
  end
  alias create_with create_model
end
 
Spec::Runner.configure do |config|
  # only include for Model examples
  config.include(ModelExtensions, :type => :model)
end

In the past I’ve used several more extensions, especially when it comes to specing controllers (controllers and their specs drive me nuts with there repetitive patterns). I often go back and forth. It’s a battle between DRYness and obscuring the specs. Based on experienced its almost always (just plain always?) best to err on the side of maximum readability at the expense of DRYness. Although I don’t think the above example is too bad, sometimes I just can’t help myself.

• FireBug
• Web Developer
• Delicious Bookmarks
• Tab Mix Plus
• YSlow
• PermaTabs
• Resizeable Textarea

I only use these at work where it’s Windows. Brief, I use for intranet feeds otherwise I use Google Reader.

• IE Tab
• ColorZilla
• Brief

You may be wondering whether or not you should care about this weblog. I’ll be discussing Ruby, open source, some .Net stuff since that’s a lot of what my day job is, web development, internet technologies like XMPP and other things related to software development such as source control and agile. Lastly, I’ll occasionally throw in some things that interest me outside of technology like running and movies. If you’re interested you can read more about me.

I’m not much of a writer or grammarian (despite the efforts of my AP English teacher) so please forgive me in advance. The grammarati can correct me in comments if they like, maybe I’ll learn a thing or two.