Advantages of Hudson and Sonar over manual process or homegrown scripts

Question

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.

Answer 1

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.

Answer 2

Setting up a continuous build tool isn't hard. It's pretty easy with Cruise Control, and my understanding is that Hudson is even easier. If you already have a one step build with maven, it's something you could probably get mostly done on your laptop while you're waiting for some dreary hour-long meeting to finish. It's not even as hard as wrapping your mind around maven. Just do it, on your own dev box if need be, and tell them how long it took you. In most organizations, having something done beats any theories about how hard it will be to implement or learn for the rest of the team.

If you set up a maven deploy goal, you'll even have something pretty close to one-click deployment. That's really, really nice. It will make you more sane. I've worked in places that have such niceness (either done by me, or by a really good build engineer), and it makes all the difference. You get stuff done, tested, and fixed much more easily, and you fear change less. It's healthy for the organization.