One-Click Builds

We want to make invoking the build as simple as possible. So simple in fact, that it becomes a non-event that’s nearly invisible to us.

The build should be accessible from the desktop or in the IDE. It should require only a single click to invoke.

First, a local build should be invoked, compiling only those modules that have a direct dependencies on the changes that have been made. Once those modules have been recompiled, the corresponding unit tests should be invoked and if all of them pass, the code should be automatically promoted to the build server to be integrated within the system and invoke a larger suite of unit tests. If all of these tests pass, then the system can actually promote it to production, if desired.

All of this can happen automatically, with a single click on the developer’s machine.

Of course, we don’t have to release to production whenever a developer has a successful build but we could if we wanted to. By making the build automatic we’ll run it more frequently and reap the benefits of feedback from our build system more consistently.

There are even tools that run the build for you automatically as you’re typing code, so you don’t even have to bother with that single click to invoke the build.

NCrunch for.net (http://www.ncrunch.net/) and infinitest for Java (http://infinitest.github.io/) are plug-ins that runs in the background waiting for developers to type keystrokes into their IDEs. When they type something in that can be compiled, a build is automatically launched. This means that you can be happily typing along and when you come to the end of the line and type semi-colon, the system automatically builds what you typed and within a few seconds you get feedback on whether it worked or not. This can be immensely valuable and speed up developer’s workflow significantly.

A single click may not seem like a lot of effort but we invoke the build many times a day when we’re writing software. Making it easy to invoke the build can have are reaching implications for improving developer’s productivity. Getting immediate feedback on what’s being built is also immensely helpful. It gives us the opportunity to find bugs as they’re written so we can fix them immediately and with little effort. When a bug gets past the developer and QA finds it days later it can take much more time for the developer to go back, figure out what she was doing, understand the bug and fix it.

We want developer to run the build all the time because every time they run the build there is an opportunity to get feedback. If the build fails then it was probably caused by something done since the last time the build was run, which is usually just a few minutes ago so it’s easy to find. If the build is successful then our confidence rises because we know things are working as they should.