My coworker and I recently got into a debate over a proposed plan at our workplace. We've more or less finished transitioning our Java codebase into one managed and built with Maven. Now, I'd like for us to integrate with Hudson and Sonar or something similar. My reasons for this are that it'll provide a 'zero-click' build step to provide testers with new experimental builds, that it will let us deploy applications to a server more easily, that tools such as Sonar will provide us with well-needed metrics on code coverage, Javadoc, package dependencies and the like.He thinks that the overhead of getting up to speed with two new frameworks is unacceptable, and that we should simply double down on documentation and create our own scripts for deployment. Since we plan on some aggressive rewrites to pay down the technical debt previous developers incurred (gratuitous use of Java's Serializable interface as a file storage mechanism that has predictably bit us in the ass) he argues that we can document as we go, and that we'll end up changing a large swath of code in the process anyways.I contend that having accurate metrics that Sonar (or fill in your favorite similar tool) provide gives us a good place to start for any refactoring efforts, not to mention general maintenance -- after all, knowing which classes are the most poorly documented, even if it's just a starting point, is better than seat-of-the-pants guessing.Am I wrong, and trying to introduce more overhead than we really need? Some more background: an alumni of our company is working at a Navy research lab now and suggested these two tools in particular as one they've had great success with using. My coworker and I have also had our share of friendly disagreements before -- he's more of the CLI for all, compiles Gentoo in his spare time and uses Git and I'm more of a Give me an intuitive GUI, plays with XNA and is fine with SVN type, so there's definitely some element of culture clash here.
Advantages of Hudson and Sonar over manual process or homegrown scripts
testing;builds;metrics
Consider what buys you the most and when.My guess is that you want to use Hudson for a build server, and Sonar for providing quality metrics.The build server is crucial and essential!  You should only send binaries out of the house built and tested by the build server directly from the sources in your source control system.  For your internal housekeeping the build number should be embedded in the binaries sent out of the house.  The value of this simply cannot be overestimated!  The quality metrics are nice, but do you need them right now?  I would expect that it is less important than the build engine and therefore I would postpone them until your coworker is ready for more.You will find it VERY easy to do Maven builds with Hudson.  So do that, and save Sonar for later.Note that there are RPM's available for Redhat based Linux systems providing for automatic upgrades with yum which is nice.And just for the record:  Use products for these kinds of things.  Do not build them yourself, especially not for maven builds.  