You don’t always get to begin at the beginning. Take something like Simian, FXCop, or NDepend. If you are trying to work any of them into your build and you already have a significant codebase you can’t really have them fail the build. Chances are you would have a significant number of failing issues with any of these products. I have found that adding things like NDepend to the build without allowing it to cause the build to fail just adds white noise. There needs to be something that instigates the developer to take action. They will not magically take it upon themselves to move assemblies out of the zone of pain. So if you can’t let existing issues fail the build the next best thing is to be making progress. To be moving in the right direction or at the very least not getting worse. You could fail the build for new issues.

Recently I posted about a new package for CI Factory: the Threshold Package. This package helps you create scripts to monitor and take action on information produced in the build. One could add a script to monitor the Distance of all the assemblies, if an assembly moved closer to the zone of pain you could send and email communicating what should happen to rectify the situation or even fail the build. If it moved closer to the sweet spot you could send a thank you email. Combined this with some direct communication from the team lead explaining that the assemblies in the zone of pain need to be fixed and you should be on your way to a better place.

Using the example of Distance as a template you can apply this to Simian’s duplication metrics as well as FXCop standards. The concept is inform and even fail the build when things get worse. Don’t forget to thank developers for improving things.

Post a Comment | Trackback URI | Views (998)