Information Technology Reference
In-Depth Information
• Logging verbosity
• Application server configuration
• Database connection information
• Framework configuration
Although the environments that you test or deploy to may be dif-
ferent, the build scripts do not need to be different. Configuration files
(such as .properties or .include files) let you account for variations
rather than having to copy and paste values for each environment
within the build scripts. Here is another area, just like source code,
where duplicated code leads to greater complexity and lower reliabil-
ity. To ensure that you can create working software in any environ-
ment, improve your build's configurability by parameterizing the build
scripts. As demonstrated in Figure 4-4, you can run the same build
script and provide an associated properties file to customize for each
build environment. For instance, you can call this build script:
ant -f build.xml -Denvironment=qa
when deploying to the QA environment.
environment
is a property
that was defined in the Ant script.
-D
indicates it's a system parameter
passed to the Ant script.
There are different types of builds, and each type has different, but
sometimes overlapping, parties who are interested in the build status or
who also will use it. These builds can be triggered using different
mechanisms, such as user-driven, scheduled, polling for changes, and
event-driven mechanisms.
Build Types
Build types occur in a three-level hierarchy: for the individual, the
team, and users (the customer). A developer (or pair) runs a private
