John is an experienced consultant specialising in Enterprise Java, Web Development, and Open Source technologies, currently based in Sydney, Australia. Well known in the Java community for his many published articles, and as author of Java Power Tools and Jenkins: The Definitive Guide, and founder of the open source Thucydides Automated Acceptance Test Library project, John helps organisations to optimize their Java development processes and infrastructures and provides training and mentoring in agile development, automated testing practices, continuous integration and delivery, and open source technologies in general. John is the CEO of Wakaleo Consulting, and runs several Training Courses on open source Java development tools and best practices. John is a DZone MVB and is not an employee of DZone and has posted 125 posts at DZone. You can read more from them at their website. View Full User Profile

Boss, We Need a New Build Server

  • submit to reddit
This is a short article I wrote for the Devoxx conference, and which appeared in one of the Parlays magazines that was distributed during the conference. The Devoxx conference is a fantastic conference, the European equivalent to JavaOne - if you can ever get to attend one, do so!

Yes, I know we already have one, an old one that some teams are using on their projects. It’s a pretty basic setup. It monitors our Subversion repository for changes, and, if it spots any changes, checks out the latest version of the source code and runs a build. For some projects, the checks are every hour or so; others run nightly builds, while still others have abandoned the idea completely because they are sick of maintaining the XML configuration files that control the builds. Anyway, should the build fail, the build server sends an email to all the team members so that someone can investigate and fix the problem.

That’s all fine, but the configuration hasn’t evolved in a very long time, and is really starting to feel its age. You see, it’s basically a glorified scheduler. Modern, state-of-the-art build servers (or Continuous Integration servers, to use the techie term) can do so much more than that. For one thing, there is always a fair delay between when a developer checks in some changes and when the emails go out alerting everyone of a crash. The other day, for example, some guy in that team on the other side of the world committed some changes that broke the build. Not a big deal in itself, but he committed those changes at the end of the day over there. Sure enough, the email notifications went out, but by the time they did, the only one there to read them was the cleaner! So when we got to work the following morning, the build was broken, and we were stuck for the day!

We need to know about build failures faster than that. In fact, whenever someone makes a change that breaks the build, I want to know who made the change, what code was modified and why, what JIRA issues were involved, and what tests it broke. I know that sounds a lot, but there’s more. I want to know within minutes. Mail is sluggish, and not all the developers read their mail immediately. We should set up a system of much faster notifications, using technologies such as Instant Messaging or SMS, so that there can be no more missed build failures.

Best practices

It could help with the development practices initiative we were discussing the other day too. As you know, we have been trying to standardize our development practices and coding conventions, as people lose a lot of time switching between projects. Every team seems to do things so differently! Each time you switch to a project, you need a day just to understand the build script! If everyone observed the same basic best practices and conventions, switching from one project to another would be a lot smoother, and new team members could be productive a lot more quickly! We have been looking at tools like Maven, which help define a standard directory structure and build life cycle across all projects. We’ve also been investigating code quality tools like Checkstyle and FindBugs, that help ensure that people follow the same coding conventions and observe common coding best practices. They even pick up the occasional bug before it even gets into Subversion! If we could integrate these into our build server, we could make sure that everyone sticks to the company conventions. With modern IDEs, it’s not too hard to do once you are aware of the standards. It would also be a great way to train new staff!

Our application architecture is a bit of a mess in places, too. The code needs to be more modular, with a better understanding of exactly what libraries each module needs. Joe has written a really useful API called cool-tools.jar. Everyone is using it. Problem is, everyone has a different version, and they’re all called cool-tools.jar! And they aren’t all compatible, so upgrading from one version to another to get a cool new feature is a nightmare!

A well tuned build server would also make it easier to isolate those hard-to-find bugs. Take last week, for example, when the users were complaining about those big performance issues. They started happening sometime over the last few weeks, but no one knows exactly when, or why, they started. We do know that the tests have been taking a long time to run of late, but no one has been taking much notice, as there is no obvious test failure. If we had a build server that kept track of how long each test took to run, we could check to see when the tests had started to slow down, and what code changes were made at this time. So, even if the tests aren’t failing, we could still figure out why performance has taken a nose-dive.


Another area where we really need to get our act together is testing. Not QA testing, I mean developer testing. See, when a tester finds an issue, it is usually weeks after the code was written. It can take us developers quite a while to shift back into that old code and figure out what’s wrong. Now I’m not saying we don’t need tester testing. We do. It’s just that the sooner we detect errors or regressions, the easier they are to fix. So we need to make sure everyone is doing their bit, and that we have well-tested code in all of our apps. What we need are more efficient ways of testing. To test more effectively with less test code. And we need to coach everybody with these new techniques, until testing becomes second nature, because, in reality, it’s not that simple.

There are plenty of good testing tools and techniques out here that can help us improve our game. Some people are using a technique called ‘Behavior-Driven Development’, to make sure that their tests are as relevant as possible, and that they are really coding to the requirements. Others are using new languages like Groovy and easyb to make their tests more expressive, and to do more in-depth testing with less code. And others are using new features in the latest version of JUnit to write their tests more efficiently. There’s plenty to be done. So, as I said, we need a new build server, Boss.


fig-1.jpeg4.82 KB
Published at DZone with permission of John Ferguson Smart, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jeroen Wenting replied on Sun, 2008/12/28 - 6:55am

you need a NEW buildserver? I can't get one at all... Not that it matters much as we can't get a decent version control system or issue tracker either.

Mittal Bhiogade replied on Sun, 2008/12/28 - 9:28am

Title does not do justice to article.

Alessandro Puzielli replied on Tue, 2008/12/30 - 3:38am

The problem is'nt a NEW or OLD Build server.

The problems is to have A BUILD SERVER!


Slava Imeshev replied on Tue, 2008/12/30 - 3:36pm


Viewtier has some useful articles on build management. They might help to convince your boss to get you a new build machine.


Eric Minick replied on Fri, 2009/01/02 - 8:42am

This is really well done. Dependency management to handle the cool-tools.jar problem is something most people overlook when finding a build server. It's great that you have that on peoples' radar.

That said, we really should be past the point of being stuck for the day just because the build is broken. Between subversion and your build server, it should be easy for you developers to either rollback the offending changes or at least update their local workspaces to the latest good state

 Overall, though, this is really well done. People should be expecting more from their CI servers rather than just settling for whatever was the hot tool five years ago (or today).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.