This document considers various aspects of application build environments & their automation, including the target audiences, day-to-day use cases, formal requirements, and potential future directions of development.

Target Audience

Before considering what an application build environment should entail, it is neccessary to understand the target audience, ie the ultimate users of the tool & how they work. The first grouping that can be easily applied is to distinguish between software developers and package distributors. The former are involved in creation of original applications, while the latter are 3rd parties who would package and distribute existing applications.


Package distributors for an application may exist both within the same organization as the software developers, or as external 3rd parties working idependantly on applications obtained from upstream developers. In both scenarios, however, the needs and mode of working of this group are fairly similar.

The packaging of any single application is a task that may not occupy a packager full-time, major bursts of work when refreshing the package with latest upstream sources, are interspersed with minor work patching for security fixes, etc. Thus the frequency with which new package releases are created and pushed through the build systems is relatively low.

Software Developers

This group ranges from the single developer, through a group of developers collaborating on an application, to a multiple groups of developers working on a set of inter-related applications. Regardless of the scale of the project, there are some common facets to the development process and developer's needs:

The key differences between the working practices of software developers and package distributors can be summed up in three points

Build environment automation

This section of the document examines some of the requirements for software build environments

The need for automation

The idea of automation is key to any software build environment.

The 'end-to-end' process

A core feature of a successful build environment is that it be a capable of providing a completely automated end-to-end process, with no need for manual interaction at any stage. At the same time, the process should be totally self-contained, with no part of it relying on artifacts previously built and setup by a developer. Depending on the requirements of a particular development team, the process would thus include:

Why the 'end-to-end' process is important

To understand why it is so critically important to provide the complete end-to-end build process described above, it is worth considering some of the problems that arise when this methodology is not applied:

Project comprehension

The term 'project comprehension' refers to the idea of collecting, organizing, analysing, and presenting information about the software build process. Quick and efficient access to information about a project's build process is essential regardless of the size of the development team. The build environment plays a major part in project comprehension, from the generation of build logs, through execution of code analysis tools, to presentation of build output. A handful of the areas of project comprehension which fall under the build environment are


For an automated build environment to be succesfully deployed within an team, its integration capabilities are a key aspect. Developers are typically very averse to changing their existing practices, particularly if the suggestion for change comes from people outside of the immediate development team, be they managers, or 3rd party consultants. Thus it must be easy to integrate build tools with any set of existing development tools, without requiring the entire software stack to be changed.