Neutral build

A neutral build is a that reflects the current state of the  checked into the source code  by the, and done in a neutral environment (an environment not used for development).

Definitions
A is a neutral build that takes place automatically in a  project. These typically take place when no one is likely to be working in the office so that there are no changes to the during the build. The results of the build are inspected by the arriving programmers, who generally place a priority on ensuring the recent changes to the source code have not broken the build process or functionality of the software. Nightly builds also ensure that the build tools have not broken due to system updates, and are therefore often run whether any source code has changed or not.

In contrast, environments automatically rebuild the project whenever changes are checked in – often several times a day – and provide more immediate feedback; however, they do not necessarily include nightly builds. As a result, compiler and tool updates may break the ability to compile older projects easily without warning. Nonetheless, CI techniques are considered the more modern approach. CI jobs are often run on isolated, and typically include automated testing as well.

When someone says a developer "broke the build", they are effectively saying that a developer checked in code which might very well have compiled (and hopefully also run properly) in their account, but does not compile (and therefore, cannot be run) in anyone else's account. This is typically due to additional developer-specific changes that were either not checked in, or (in the case of s, etc.) were modifications to systems not under. One of the most common cases is remembering to check in all modified files, but forgetting to add newly created files to the repository. If the other developers check out the new code without being aware of the problem, their work may grind to a halt while they wait for the problem to be fixed (or try to fix it themselves, which can be even more problematic, if multiple developers attempt to fix the issue at the same time). This naturally can result in a significant loss of productivity.

Neutral builds are important for processes running at high loads with short schedules (see, ). Not having them means that any build that needs to be created for the department will use code that may be in the middle of major modifications, and which is therefore best left out of a build intended for independent validation – particularly a build being evaluated for possible release.

Hazards
Some obstacles to a reliable neutral build process are:


 * Getting a consistent and set of project control files.
 * Having the same operating system and tools setup as the development machines.
 * Set up a checkout procedure that ensures all files are up to date. This may imply the additional task of integrating a with the process.
 * Decoupling the build process from specific.
 * Setting up adequate feedback from the build system so that failed builds can be diagnosed.
 * Convincing management of the benefit of automated builds.

Open-source examples
The following list gives some examples of software that has publicly available nightly and/or neutral builds.
 * , an open-source custom ROM for Android-based devices.
 * Firefox, an open-source web browser.
 * , an open-source media player.
 * , an open-source transportation simulator.
 * VLC media player, an open-source media player.
 * WebKit, the web browser renderer used by Google Chrome and Apple's Safari.
 * , Arduino is a family of, intended to make it easier to build interactive objects or environments.
 * , RetroArch is an emulator for different consoles such as PlayStation, NES, Game Boy etc.
 * , WYSIWYG music notation, generates Linux nightly builds in the format of a distro-agnostic.