Information Technology Reference
In-Depth Information
Ideally, an integration build should run on a separate, dedicated
machine.
Fowler
5
discusses different types of builds that can be run as part
of an integration build. He calls these “staged builds,” which include a
“commit build” and “secondary build(s).” A commit build is your fast-
est integration build (< ten minutes) and includes a compile and the
unit tests. A secondary build is an integration build that runs slower
tests, such as component, system, and performance tests. It can also
include automated inspections such as coding standard adherence and
code complexity.
Release Build
A
release build
readies the software for release to users. One of the
goals of CI is to create deployable software. A release build may occur
at the end of an iteration or some other milestone, may include more
extensive performance and load tests, and must include any acceptance
tests. Moreover, many release builds also create the installation media
to run it in the user's environment. A release build may also be used to
ready it for QA, if you are using a separate, staged process and team.
Build Mechanisms
Not all builds are triggered in the same manner. To trigger a certain
build in the most appropriate manner, you must consider the build's
purpose and frequency. In some situations, there may be scripts that
are so large or have so many dependencies that it shouldn't be run
automatically; instead, it should always be run on demand. In other
cases, the automatic execution can be run under CI. The following list
describes the types of build mechanisms.
•
On-demand
—This is a user-driven process in which someone
manually initiates an integration build.
•
Scheduled
—Scheduled processes are driven by time, for
instance, so that it runs on an hourly basis, whether or not a
5. See Continuous Integration at
www.martinfowler.com/articles/
