A number of people work together to develop a software application. The application is useful only when the components each person works on come together - the process of integration. The mechanics of integration happens during a build. Last month we discussed continuous integration. "Integration" implies "building" and this month we'll talk about the various kinds of builds one does during a development process.
To make sure that we understand each other, let's start by defining some terms that we'll be using in the article. Hopefully the definitions are similar to the ones that you use; but if not, there should be a simple mapping from your terms to ours.
A Build is the process step where you integrate all or part of your application. The build can include steps like retrieving the correct components from various locations in the Repository, compilation, running scripts that generate source files from meta-data, etc. In short, anything necessary to go from a set of source files in your version management system to a component that provides value to someone. The product of a build can be a complete application or a component for distribution.
The inputs to a build are " source components " which include source files, meta-data files, and pre-compiled third-party library components.
Builds can be full (a.k.a. "clean") or incremental (a.k.a. "dirty"). An incremental build makes use of a dependency checking system so that you only build derived components from source components that have changed since the last build. A full build starts with no derived components.
Builds are often orchestrated by build scripts, which can be makefiles, Ant scripts, batch files, etc.
Building and Agility
Agile software development is based on a feedback loop between the developer and the customer. The development team implements functionality based on customer input, the customer evaluates the current state of the product against their list of requirements and the schedule constraints, and the team starts a new iteration to implement the next set of functionality.
This feedback cycle works best when the time between iterations is "small." What "small" means depends on your team and process that you are using. XP teams typically use iterations of 2-3 weeks, Scrum teams use slightly longer cycles. Regardless of the customer iteration length, it is important to monitor the state of the process so that the system does not degrade unexpectedly. On the other hand, if you spend too much time on monitoring, you will have that much less time to do development of new features.
Important as it is, you should develop build (and deployment) processes early on in the project so that they evolve as the product evolves and so that they don't take up much time. The build is an infrastructure step that helps you to create a product. It is not an end in itself.
Agile software development depends upon a hierarchy of build practices that allow you to balance the need for speed and the need for stability.
Writing build scripts early does some of the same good things for your architecture as test-first development does.
Kinds of Builds
We've identified three patterns for builds: Private System Build , Integration Build , and Release Build . Each type of build has a different scope and frequency to resolve a slightly different set of concerns for its target consumer.
- Private System Build , for building a system to use for testing in your Private Workspace. The consumer for this build is the developer doing ongoing work.
- Integration Build , to integrate everyone's changes in a central place. The primary consumer for this build is the development team, both for the purpose of having additional assurance that the code integrates in a "clean" environment, as well as for integration level testing in advance of the release of the software.
- Release Build , which packages the software for release. The consumers of a release build are the testing team (for pre-release) testing, and the customers