Posted by johnsmart
on December 18, 2008 at 5:28 PM PST
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 conï¬guration ï¬les 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 ï¬x the problem.
Thatâ€™s all ï¬ne, but the conï¬guration hasnâ€™t evolved in a very long time, and is really starting to feel its age. You see, itâ€™s basically a gloriï¬ed 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 notiï¬cations 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 modiï¬ed 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 notiï¬cations, using technologies such as Instant Messaging or SMS, so that there can be no more missed build failures.
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 deï¬ne
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-ï¬nd 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 ï¬gure 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 ï¬nds 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 ï¬gure 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 ï¬x. 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 efï¬cient 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 efï¬ciently. Thereâ€™s plenty to be done. So, as I said, we need a new build server, Boss.
"Best development course I have been on in a very long time...Greatly enjoyed the course...A 'must' course for serious Java developers..." - Read what people are saying about the Java Power Tools Bootcamps.