I’ve seen a lot of build scripts over the years. I am surprised when good software developers that follow good practices when developing the application software seem to forget these practices when writing their build scripts. Without following some basic effective practices, these build scripts can get unwieldy in short order. If your build scripts are not maintainable, you may get diverted from developing the application software - at the most inopportune times. In no particular order, I’ve listed some of the more common bad build scripting practices I’ve seen. The examples are in Ant, but apply to any build scripting platform. In this first entry, I will demonstrate five “bad build practices”. My next entry will include the other five bad practices I’ve observed…and, of course, I have committed from time to time

Bad Practice One: Hard-coded values
This is a definite no-no. For instance, in hard coding a value, you could make the script dependent on a particular directory being present on each computer. Without changing the script, you’d need to copy these files to each computer on which you build. To eliminate the use of hard-coded values, use relative references and be sure the files/directories are checked in your version control repository so that they are available from your local workstation.
Bad:
<property name="config.dir" value="C:\projects\finanit\implementation\config" />
Good:
<property name="config.dir" value="${basedir}/config" />

Bad Practice Two: Copy and Paste build scripts for different environments
For instance, you may need different build behavior for each environments - such as development, QA and Staging. Some choose to copy and paste their build script and make the minor modifications in each script. In doing this, you’ll experience the same problems when copy and paste programming. One solution is to put the common behavior in a single build script and use a .properties file to adapt to each environment. The concept is similar to using a base class for common behavior in OO programming. The left side of the image below is the “bad” in which the same copy of the file has been used and slightly altered for each environment. In the right side of the image below, the build.xml has been generalized to account for different environments. You make the changes to the .properties files instead of different copies of the build scripts.

Bad Practice Three: Long targets
Just like long methods decrease the maintainability and understandibility of your source code, so do long build targets in your build scripts. Try to break up build behavior into discrete targets.

Bad Practice Four: Not cleaning up after yourself
If you are not removing temporary files, classes, assemblies and other files before you build, you have no way of ensuring the build was successful. If you need to get the same version of a build at a later time, you may have difficulty in creating it. What’s more is that you may not discover a defect (or chasing a latent bug) until later in the development cycle.
Good:

  <target name="clean">
    <delete dir="${classes.dir}" quiet="true" />
    <delete dir="${reports.checkstyle.dir}" quiet="true" />
    <delete dir="${checkstyle.classes.dir}" quiet="true" />
  </target>

Bad Practice Five: Building with the IDE only
There’s no problem with using your IDE to build the software. In fact, I’d encourage to use it to build. However, if your build script executed from your IDE is different than the build script you run from the command line (e.g. using Ant/NAnt) then you are asking for problems. This is particularly difficult to manage if each developer has his own variation of the build script(s). Building software should be consistent and repeatable. An effective build process begins with all developers using the same build script(s).