Neutral build

From Wikipedia, the free encyclopedia

This article or section does not adequately cite its references or sources.
Please help improve this article by adding citations to reliable sources. (help, get involved!)
This article has been tagged since February 2007.

In software development, a neutral build is a build that reflects the current state of the source code checked into the source code version control system, without any developer-specific changes.

A nightly build is a neutral build that takes place automatically, typically when no one is likely to be working in the office (which, for programmers, often means this needs to happen at 3 AM or later). The results of the build are inspected by the arriving programmers, who generally place a priority on ensuring the neutral build does not break.

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 environment variables, etc.) were modifications to systems not under revision control. 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 software development processes running at high loads with short schedules (see extreme programming, startup); not having them means that any build that needs to be created for the Software Quality Assurance department has to be created using code which may be in the middle of major modifications, and which would best be left out of a build for testing (particularly a build being evaluated for possible release).

Neutral builds can be done on a machine which is also used for active development if enough caution is taken, but it is wiser to dedicate a machine to that purpose, and that purpose alone.

[edit] Hazards

Some noteworthy obstacles to a reliable neutral build process are:

Getting a consistent set of makefiles and other project control files. This step tends to expose consistency problems between various development machines, particularly with respect to directory structures, compiler and linker options, and environment variables.
Having the same operating system and tools setup as the development machines. Again, this step tends to expose differences between the machines in use by different developers.
Having an automated checkout procedure that completely cleans out the target directory first, and gets all files required. Ideally, however, the system doesn't waste time with large files that aren't required.
Integrating with the version control system, particularly if encryption, authentication, or both are being used (see SSH). This must be done with care, as it is typically very easy to make it "work" without being secure, and the temptation or pressure to just "fix it later" may be strong.
Ensuring all materials come from the correct directory. It is strongly recommended that there be only one copy of the source tree on the neutral build machine.
Figuring out how to number versions. Expect this to launch a lengthy debate. Expect to repeat the debate when you talk to QA. Expect to repeat it again when you talk to management, and they explain that a particular version number will be required for the CD label, and it would be nice for everyone if the internal build numbers made sense in light of that. A target version number (major.minor.trivial; i.e., 1.2.4), and a build number, and a string of freeform flags, may be a good option. Make sure everybody understands whether a minor rev to "1.9.2" produces "1.9.3", "1.10.0", or "2.0.0", and so on. This problem is much easier to solve up front. Also, internally, a software release can have any number on it whatsoever. The official release version can be a completely different numbering schema.
Decoupling the build process from specific IDEs. This is tough to convince some people to do, but in the end, it leads to cleaner build processes. Trouble usually arises in areas such as EJBs (especially with IBM's WebSphere product which requires the use of one of their IDEs to generate some binary files).
Getting adequate feedback from the build system so that you can tell what is broken when something breaks. The worst kind of feedback is simply a lack of linked binary files; the best identifies not only compilation failures, but linker failures, missing source materials, missing include directories, and so on.
Understanding the difference between branching and releasing. Releasing software requires a branch whose state can be returned to. A release is usually a tag on a branch or mainline like the HEAD. A branch can be used for parallel development or for patch releases to a release. A branch is not necessarily a release.
Ensuring developer environments are easy to set up and get into a useful state. The varied state of machines and software installations can make this task quite daunting.
Convincing management of the benefit of automated builds.