In this whitepaper I argue that the person most affected by the introduction of agile or extreme programming techniques is not the software or quality assurance engineer, but the build manager. And the build manager can no longer make do with home grown tools; software production automation tools are required to make agile development a build reality.
The reality is that agile techniques are a throwback to the age when developers were able to work on small projects in small teams. Each developer (or sometimes pair of developers) concentrates on small building blocks of code (with associated unit tests), and integrates regularly with other developers to ensure that the overall software project is progressing. For developers, agile techniques are a natural fit because they reflect how developers like to work best: on small, manageable pieces of code with regular feedback.
The Agile Heartbeat: How Agile Development puts fast, automatic builds center stage and requires a new approach to software production. By John Graham-Cumming Co-Founder and Chief Scientist, Electric Cloud, Inc.
Introduction
In this whitepaper I argue that the person most affected by the introduction of agile or extreme programming techniques is not the software or quality assurance engineer, but the build manager. And the build manager can no longer make do with home grown tools; software production automation tools are required to make agile development a build reality. The reality is that agile techniques are a throwback to the age when developers were able to work on small projects in small teams. Each developer (or sometimes pair of developers) concentrates on small building blocks of code (with associated unit tests), and integrates regularly with other developers to ensure that the overall software project is progressing. For developers, agile techniques are a natural fit because they reflect how developers like to work best: on small, manageable pieces of code with regular feedback. Even though developers are working on small sections of code, the overall projects they are part of are now very large. So there's no going back to a small build on a single machine for build managers. While developers may have broken their work down into small units that they can code and test, the overall size of most enterprise software projects is constantly growing. And it's the large body of code that the build manager is expected to work with, not the manageable chunks that developers deal with. In fact, the build manager is expected to cope with ever larger software, on ever more platforms, while at the same time dealing with developers' requests for fast integration builds. Those integration builds enable agile development at the software engineer's desktop because they are able to integrate their local changes into a large build, but cause build managers to be
v2007.01 2 whitepaper ŠElectric Cloud, Inc. All rights reserved. required to produce one or two orders of magnitude more builds per day. All these changes are brought about by one central tenet of agile development: continuous integration.
Continuous Integration
The seminal paper on Continuous Integration (and an excellent, and readable introduction to the topic) is Martin Fowler's article entitled, simply, Continuous Integration and available at UTUThttp://www.martinfowler.com/articles/continuousIntegration.html. Its abstract states: Continuous Integration is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. To the build manager the words 'multiple integrations To the build manager the words 'multiple integrations per day' and per day' and 'each integration 'each integration is verified by an automated build' mean a radical is verified by an automated change from once-nightly builds. build' mean a radical change from once-nightly builds. Fowler goes on to list a number of 'Practices of Continuous Integration'. The first build-related practice is 'Automate the Build'. He argues that the set of tasks required to go from source code to the final shipping binary is so complex that it should be automated so that it is repeatable. If the build is not automated, he argues, the build process will be error prone. He also argues that the build includes much more than just compiling the software and building a binary. He sets the goal of 'anyone should be able to bring a virgin machine, check the
v2007.01 3 whitepaper ŠElectric Cloud, Inc. All rights reserved. sources out of the repository, issue a single command, and have a running system on their machine'. It's worth stopping and thinking about the implications of that statement for your build organization. It's very likely that getting to such an automated stage seems impossible, when starting from what is often a creaky build system held tog... [download for more]
