Build, in the context of software development, refers to the process of converting files (and other assets) into a software product in its consumable or final form. The build can include:
– The compilation of the source files.
– Packaging compiled files into compressed formats (such as jar, zip).
– Creation of the installer
– Create and update the database schema or data.
– The build is automated when the steps are repeatable, require no direct human intervention and can be performed at any time with little to no information other than what is stored in the source code control repository.
– Build automation is basically the effective use of continuous integration. But it brings it’s own benefits:
– It deletes a source of variation, eliminating defects; a manual build process containing many necessary steps offers more room for mistakes.
– Requiring thorough documentation of expectations about the target environment, and of assurance on third party products.
– The practice of build automation should not be confused with continuous integration: the build automation consists of “executing” the build process as frequently as possible (the idea is that whenever the code changes, it automatically checks the source code control repository) and “verifies” the validity of the resulting product, in particularly by unit tests.
– The continuous integration tools (such as CruiseControl, Hudson, etc.) belong in a diferent category from build automation tools (Maven, rake, etc.)
– Being able to trigger some build operations from within a development environment (IDE) is usually not enough: 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).