|
|
|
|
|
Neutral BuildIn 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). Needless to say, this 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 QA 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 purpose alone. 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.
- 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.
|
 |
|
| Copyright 2005-2009 OnPedia.com. All Rights Reserved |
|
|