Development process best practices suggest to define a reference environment for testing and promotion configurations to the next step of development lifecycle, to ensure that local configurations aren't masking defects in the official implementation. This is normally addressed with continuous integration tools such as CruiseControl or Continuum, often integrated with Ant or Maven. The common notion is to have a separate build machine to be used as a reference environment taking source files directly from the SCM system. This way you can ensure that reference environments works regardless bad influence of developers that move far away from the baseline, by avoiding to commit or update for a long time.

A more interesting way to solve this problem tough, is to randomly choose a reference environment: stating that "This week, production environment will be aligned with... Bob's machine!!" or whoever. And once the choice is made, pour the code straight to production. You'll get sure that developers start running test on their machines...

Labels: continuous integration, test driven development

Hi, my humble proposal for today is a tool that integrates quality assurance tools such as Checkstyle, or PMD in a JBoss deployment engine. A quality assurance step should generally be a part of a wel defined release process and integrated in Ant or Maven building facilities. Life is normally harder than this and barbarian hordes might easily cross those fences, so we need another defense line before "the application that barely compiles" can make it to production.

The main idea is to have JBoss refuse to deploy applications which don't meet certain quality standards. To make it more effective we absolutely need to include a sarcastic engine for log messages, such as

• "Do you really think I am gonna run this crap here?"
• "Hey, who is the dork that created 15.000 String instances in a loop?"
• "Hoo, hoo! ...and who do you think is going to catch these exceptions? Fix the damn code (you know where, no way I am telling you...) and come back when you're done!"
• "Go to the whiteboard and write 100 times: I will never ever deploy a 20.000 lines class"

A more powerful version of the tool should track versioning too.

• "Hmmm, still here... fourth version in four days... I guess you are getting some ...feedback from the users, aren't you?"
• "Here we go again, maybe this one is the time you can get close to fix bug 344, or maybe not."
• "Come on, this time you can make it, yes, getting close to it.... No! Missing a library (as always)... Loser"