Automated Builds and Process

I’ve always been a big fan of build systems that work for the developer. I really don’t think that a single build tool (Ant, Maven, whatever) can address all the unique needs of a development organization. Typically there are always trade-offs to consider, such as how seperate should modules be (source compiled with every build, or jar files checked in to source control/downloaded by the build tool).

Vincent has been doing some thinking about build systems that is pretty interesting:

• Binary dependency builds
• Distributed build

I’m glad to see people like Vincent (and the CruiseControl team, apparently) thinking about this kind of stuff. One thing to note is that you don’t really need a lot of complicated tools to achieve a working build system. The biggest thing needed is developing the process that your entire team has agreed to follow.

For example, suppose you mandate that all sub-projects shall be “disconnected” from each other. This means that rather than having a massive build that compiles everything every time, you build artifacts (jar files) that other projects depend on. Without fancy automated tools, you might require that the newest jar files be checked in to a CVS module called “builds”. Maybe as time goes on and your infrastructure improves, you might have a way to place those jars on a website and automatically download them (Maven does this, but I don’t like it purely because I don’t “get” how it would work with my IDE). The point is that in concept, both techniques are the same. Getting your team to agree to a process is the hard part. Tweaking that process as time goes on to optimize it will come naturally.