Release-Engineering

The build script from the last post turns your source code into something runnable. But it does not tell you which version of the source code you are building. That is where version control comes in. I am going to use Subversion for this post because that is what most of the projects I have worked on have used, and it is still the most common version control system in enterprise Java development. Git is fine for other kinds of projects, but the concepts here apply regardless of which system you choose. ...

I wrote my first build script in my second year of college. It was a shell script that compiled a few Java files and copied the output into a folder. It worked. For that project, at least. Three years later, working on a team project with five other developers, I realised that script was useless. It assumed a specific directory layout. It assumed a specific version of the JDK. It assumed nobody had moved the source files. It assumed the build machine had the same libraries installed as my laptop. It assumed a lot of things, and every assumption was a potential failure point. ...

Every project I have worked on, from small college assignments to larger team efforts, has eventually hit the same wall: someone runs the build, something breaks, and nobody knows why. The code was fine five minutes ago. The build server is down. The classpath is wrong. The compiled output is three versions behind. It is frustrating, it is wasteful, and it is entirely preventable. The fix is a build script. ...