This paper looks at the needs of build and release management, how those needs are met by open source and commercial tools that go way beyond the likes of Make or Ant, and the real costs of creating and maintaining a homegrown system.
Build and Release Management: Understanding The Costs of Doing it Yourself John Graham-Cumming Co-Founder Electric Cloud, Inc.
Table of Contents
Introduction 3
Building it Yourself
1. How it All Begins 3
2. Feedback Becomes Essential 5
3. Outgrowing a Single Machine 6
4. Supporting Multiple, Distributed Machines 9
5. Monitoring and Management 10
6. Extensibility 11
How Did we Get Here? 11
The Cost 12
A Commercial Alternative: ElectricCommander 14
What Makes ElectricCommander Unique? 15
Conclusion 16
About Electric Cloud 16
2. v2007.07 whitepaper ŠElectric Cloud, Inc. All rights reserved. Introduction
If you were starting a new software development team today, could you imagine one of the 'to do' list items being 'build our own source code management system'? It's unlikely that anyone would dream of building their own SCM system today: there are multiple open source and commercial SCM systems available to meet all possible needs. But the same can't be said for build and release management where most organizations handle these processes with manual, script-driven systems. It's ironic because the most widely used build tool, Make, was created around the same time in the early 1970s as the first SCM tool, SCCS, yet build and release management has lagged behind. In the intervening 30 years SCM has progressed from simple tools to complex, commercial products as software projects have grown in size and complexity. Build and release management has only recently caught up with the release of suites of tools that simplify and improve the entire process. These tools mean that build managers no longer have to create build systems from scratch, nor are they saddled with ongoing maintenance costs for home grown systems. This paper looks at the needs of build and release management, how those needs are met by open source and commercial tools that go way beyond the likes of Make or Ant, and the real costs of creating and maintaining a homegrown system.
1. How it All Begins
Today most software development organizations do create their own build systems and they gradually end up with unmanageable, poorly documented or impenetrable code. This happens because, initially, making your own build and release system looks easy. At first a small team can get away with a simple build script. The script often grows out of the software's Makefile or Ant script by wrapping them with a little bit of Perl or some other scripting language.
3. v2007.07 whitepaper ŠElectric Cloud, Inc. All rights reserved. While the Makefile will show how to build the software, the wrapper script probably incorporates steps like checking out the source code, running smoke or unit tests and 'deploying' the software by copying it to an appropriate directory. Ambitious build managers will have included a mechanism to send an email when the build ends, perhaps even including details of the success or failure of individual steps in the process (sometimes including snippets of log files relevant to debugging a broken build). The scope of the build script is really only limited by the build manager's imagination and, more importantly, time. Some build scripts might even try to interrogate an SCM to discover who checked in since the last build, and hence might be to blame for a build failure. Once the relevant steps have been written into the build script it's The scope of the build script is really only limited possible to automate the builds by calling the script from a 'cron' job or by the build manager's similar job scheduler. It's typical to see a team install a dedicated 'build imagination and, more importantly, time. machine' which runs the build script and produces regularly scheduled builds (at least one nightly build). 1Teams that decide to do continuous integration (CI) usually start to see problems with home grown build scripts. To make CI work they build another script that monitors the SCM system for changes to a particular branch, determines when the changes have finished (by waiting for... [download for more]
