Hello Java Fan. I like your pragmatic style to solve solutions and I will also look in a further step into cfengine or puppet to see what potential they have.
To be honest I wanted to compile that on each machine for two reasons. One was because I need to evaluate two Tools: Hudson and Bamboo. I wanted to build PERL with those Tools. The Second reason is to know deeper the features that a compile had. The Perl Distribution that was on the Server didn't even support Thread, therefor I wanted to compile it myself to learn how to do that. Thank you for your support.
| [reply] |
I would, if it were me, choose a smaller and more Hudson-compatible codebase than Perl to evaluate Hudson. Perl's testing framework is extensive, but not well-supported out of the box by Hudson. (A significant amount of fiddling about would be necessary to integrate this with Hudson, and given that you are probably not going to be making updates to the Perl codebase itself, it's probably valueless for you.) I'd suggest getting Hudson building itself first as an evaluation tool, or better yet, Jenkins, as that codebase changes faster, and you'd get a better chance to evaluate the change tracking features in Hudson.
I have not used Bamboo, so I will refrain from making any remarks about it at all!
I think the approach mentioned previously, adding Puppet to the mix, is a good one; Perl's module installation stuff will work better if allowed to work in its natural manner; trying to graft more modules into the standard build is likely to prove quite difficult, especially if you're not already very familiar with the Perl build process. I'd recommend building the Perl source and making whatever standard Solaris package from that, then using Puppet or the like to run CPAN to install the modules you'd like to add.
| [reply] |