Build & Release - Tools and Good Practice

Just yesterday I was offered a new job with a relative large insurance firm in the UK. My role will be to bring the build management team up to scratch and implement a framework from the ground up. This got me thinking... what are the tools and good practices I cant live without?


Build & Release Website

Every software development outfit should have one of these! Some of the information you would store is:

• Functional Release Notes
• Technical Release Notes
• Continuous Integration Results (Link to tools)
• Project Documentation (Javadocs or LXR)
• Runtime Logs
• Deployed Applications (A list of environments and their current deployments)
• Application Metrics
• Third Party Documentation (Tools, Libraries)
• Misc Documents

This should be maintained by the Build & Release team and should be automated. Our systems are configured to deploy the documentation once its been created.

Build & Release Calendar

Another tool no serious software company should be without. The projects that you support should be able to see your workload and manage requests accordingly. Also, if you need to justify where you're spending your time this acts as a great record for the finance department or Project Managers. There are free calendars available and tools like Jenkins also provide work well with Google Calendar.

Build Framework

No sh!t, really?! It doesn't matter what tools you use, but you should be able to build, package, run unit tests and deploy at very least. The aim here is to produce a framework that can be used with very little configuration and flexible enough to use with new projects. Some of the "powers-to-be" at my office have been trying to get us to switch to Maven for a while now. The argument that we're forced to use a single framework is a fair one, but my counter argument is that our Ant framework is so well made that we wouldn't be achieving anything by switching. Ant is a highly configurable tool but takes a lot to get up and running, however Maven is not so flexible but is much easier to use "out of the box".

Continuous Integration

CI is often considered something only used by large scale projects. This doesn't have to be the case. Even if you're a small operation with only a handful of developers it makes sense to offload the task of compiling your source and running a few simple tests. To put this into context, if you have 5 developers, a build takes 1 hour and each developer builds at least once a day, thats 25 hours wasted on builds a week. At a very generous rate of £15 per hour thats £375 a week and £1500 a month wasted in consumed resources for builds. Thats the build server bought and paid for!!