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.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 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.Testing
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.