NH Prof, Error Handling, Continuous Integration and RTM per commit

time to read 2 min | 315 words

One of the nice things about NH Prof is the way that it is setup from an infrastructure stand point. Take a look at the following email:


I got this email, along with an additional one containing the actual crash information (this email is generated from the user’s input about the reason for NH Prof crashing).

This isn’t the first time that I get this bug (it is an annoying threading issue) but this time I was able to finally pinpoint the exact place where this is happening, trace it back to where it is used and get to the slap-fore-head-OMG-I-am-stupid moment.

Then it was adding a few locks, refactoring to make it clean, and commit.

At this point, my work is done. We have a CI infrastructure that will compile everything, run the tests and push it out as a released build.

With NH Prof, we take the stance that every single commit is a release. Sometimes we will do some work on branches, but most of the work is done on the trunk, and any commit to the trunk result in a new released build.

Out of close to 400 builds that we have so far, I believe that we had about 5 – 10 lemons (builds that fail on user’s machines). In all cases, it was fixed within a few hours.

The implications for me are huge. I don’t have to worry about managing things. I set it up once (sometimes in December or November, if I recall correctly) and stopped worrying about releasing stuff.

And it means that I can literally fix a bug, commit and tell the user that they can pick up the changes as soon as it is done.