Tuesday, June 28, 2005

Taming the Legacy Beast - Dose It With Some NAnt

Yesterday I griped about legacy code. I carped about VSS, whined about the tight coupling, groused about the arcane configuration setup, and spewed invective about the stupid manual post compilation steps it took just to make the code work. Today it's time to start cleaning things up and applying some ibuprofen to the legacy headache.

Even though the work we're doing is supposed to be throwaway in a couple of months, we decided to "NAnt-ify" the development environment. First we're skimming the VSS project and setting up a new Subversion repository. The next step is to create a bare bones NAnt build to automate the application setup. The last step is a simple CruiseControl.Net configuration to get it into our existing continuous integration server (this is sooooo much easier than it was just a couple of years ago. Hat's off to the CC.NET guys).

If you can't easily make a repeatable build and get the application working on your own box in short order, you're not gonna go anywhere fast. That whole NAnt/CC.NET helps keep the code clean in source control so your coworkers aren't idle while you go hunt down the new class file you forgot to add. And one last time, VSS is a piece of crap. Using the far superior clients for Subversion (or almost anything else) that are actually intelligent enough to determine what files have been changed, added, or deleted makes for a smoother source control experience. And no, we're not going to wait until November for the promise of Hatteras in VSTS when Subversion is here now and free.


Anonymous Steve Hebert said...

I think this also plays to the idea that you should not only build your project, but build the install package as quickly as possible in the process. This forces us (developers) to consider install-time issues immediately rather than pushing it off on the "install shield guy".

4:22 PM, June 28, 2005  
Blogger Nettleblogger said...

Isn't it funny how when people say "This is just gonna be thrown away", that it becomes a license not to use good engineering practices? Just the other day I was told I was "trying too hard" on project that was not "that sophisticated". I COMPLETELY agree with you that in order to prove your software works, you have to build it in it's own environment. Strange how many people miss this easy to do step.

4:45 PM, June 28, 2005  

Post a Comment

<< Home