Neutral Build - Hazards

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.
• Problems with version numbering.
• 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.