Agile Glossary

Automated Build

What is Automated Build?

In the context of software development, build refers to the process that converts files and other assets under the developers’ responsibility into a software product in its final or consumable form. The build may include:

  • compiling source files
  • packaging compiled files into compressed formats (such as jar, zip)
  • producing installers
  • creating or updating of database schema or data

The build is automated when these steps are repeatable, require no direct human intervention, and can be performed at any time with no information other than what is stored in the source code control repository.

Expected Benefits

Build automation is a prerequisite to the effective use of continuous integration. However, it brings benefits of its own:

  • eliminating a source of variation, and thus of defects; a manual build process containing a large number of necessary steps offers as many opportunities to make mistakes
  • requiring thorough documentation of assumptions about the target environment, and of dependencies on third-party products

Common Pitfalls

  • the practice of build automation should not be confused with continuous integration: the latter consists of “executing” the build process as frequently as possible (ideally whenever a code change is checked into the source code control repository) and “verifying” the correctness of the resulting product, in particular by unit tests
  • in particular, continuous integration tools (CruiseControl, Hudson, etc.) are a category distinct from build automation tools (make, Ant, Maven, rake, etc.)
  • being able to trigger some build operations from within a development environment (IDE) is usually not sufficient: as it is often the case that some build operations are not supported within the IDE, it must be possible to perform a build outside of the IDE
  • the duration of a build process should be under ten minutes, including the execution of automated tests; beyond this order of magnitude it will generally be difficult for the team to achieve continuous integration

Origins

  • 1977: creation of the “make” tool for Unix systems – the principle of automating software builds is not a new idea
  • 1990s: owing to the rise in popularity of RAD tools and IDEs, “make” type tools acquire a mixed reputation
  • 2000s: even though the practice is far from new, nor limited to Agile teams, it is partly due to Agile practices that a revival of “make” type build automation takes place

Signs of Use

The best way to ascertain whether a team practices build automation is a surprise test: ask the team to provide an installable version of the product. Measure how much time is necessary to obtain a release, then attempt to install or deploy to an off-the-shelf PC or environment – one which has not been previously set up by the development team. Any “surprise” during this process will suggest ways to improve the automated build process.

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now