Information Technology Reference
In-Depth Information
not being utilized can become the CI machine. If a dedicated integra-
tion build machine isn't available, start by using your own develop-
ment machine. This is better than not integrating at all, but this isn't a
long-term solution. Be sure to use a separate location (i.e., directory or
partition) on your machine.
There are a few items to consider when creating an integration
build machine. By focusing on these issues you'll receive the maxi-
mum benefits from it.
•
Recommended system resources
—A lot can be gained by
using the right tools. By increasing hardware resources, a build's
duration can be reduced (discussed later in this chapter). In gen-
eral, it is worth the money to increase hardware resources for an
integration build machine rather than wasting time waiting for
slow builds.
•
All software assets in the version control repository
—Any-
thing that has to do with developing the software needs to be
committed to the version control repository. This includes source
code, build scripts, configuration files, tools (such as application
server, database server, and static analysis tools), test code, and
database scripts/files (see the Centralize Software Assets section,
earlier in this chapter).
•
Clean environment
—Before performing an integration build,
the CI script needs to remove any code dependencies on the inte-
gration environment. Ensure that it is removing all of the source
code and binaries from the previous integration build in order to
baseline the environment. Also make sure that the CI system sets
test data and any other configuration elements to a known state.
This approach reduces assumptions by removing dependencies
and building the software as if it were on a new machine.
By using a dedicated build machine that is capable of running
builds efficiently, the build process can be run often; moreover, the
build environment becomes truly repeatable by reducing environmen-
tal assumptions.
