Information Technology Reference
In-Depth Information
time targeting the failed targets. The high-level steps to create fast-failing
builds are
1. Integrate components (get latest changes from repository and
compile)
2. Run true unit tests (i.e., quick tests that don't have a database or
any other dependency)
3. Run other automated processes (rebuild database, inspect, and
deploy)
This is only one recommended order of build execution. It all
depends on what is more likely to fail most often on a particular
project. The more likely it is to fail, the sooner you should have it exe-
cute within the build script. Also, keep in mind that the order of execu-
tion is sometimes dictated by what must be built first. For example,
source code needs to be compiled before running developer tests.
Builds are most effective when they send a build failure as soon as
possible. The Run Fast Builds section, later in this chapter, addresses
ways to reduce your build duration and to stage builds so that they pro-
vide faster feedback.
A software project often requires you to deploy to different environ-
ments. You may find it useful to maintain different configuration files
in your repository to execute against different environment configura-
tions (development, integration, test, QA, and production) by using
.properties, .xml, or .ini files. Each platform, language, and scripting
tool will have its own variation on configuration. A build's config-
urability relies on its build scripts to alter the predefined configurations
available in the software without changing the core functionality of the
build scripts. In many cases, you can provide these configuration
“hooks” by altering configuration files used by the application. Fre-
quently, you can also configure the frameworks and APIs on which an
application relies. The technique will vary depending on the platform's
convention. The following is a list of configurable values that you will
likely find in most environments.
