Stephen Chu, one of my former ThoughtWorks brethren, has posted a great article about using NAnt. You can find it here.
It’s refreshing to see postings like this, especially, as Stephen points out, everyones love affair with Ruby/Rails/Rake. NAnt is still a pretty good tool, and is the build tool of choice for most, if not all, pre 2.0 .NET shops out there and there are a lot.
Jay Fields, another ThoughtWorks brother-from-another-mother, posted a list of Rake links for all those wondering what the fuss over Rake is about. Jay asked me what i thought it would take for Rake to supplant NAnt/MSBuild as the .NET build tool of choice. My answer was the same answer I give to anyone who asks me about introducing a new tool into a teams toolbox. Decisions like those aren’t just technical. Very rarely does the best pure technical solution win out. You have to factor in what introducing the tool means to the team / department / company. For example, replacing NAnt with Rake because you can speed up your build from 10 minutes to 5 minutes may seem like a good idea, but think about the fact that you have to introduce a totally different language, platform, and programming environment to do it.
- What happens when the Rake champion leaves?
- What happens if the team has to integrate with a build and release team who are accustomed to using NAnt?
- What happens when you need to extend Rake to do something it doesn’t and now have to learn Ruby?
I’m not picking on Rake here. I am just saying that decisions need to involve the bigger picture, not just the immediate technical one.