This is an introduction to an internal .Net build tool written in Ruby. Although it’s not Open Source I thought some would be interested in hearing about it.
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.
Post a Comment