Information Technology Reference
In-Depth Information
save money in the end to purchase a build machine. In using the phrase
“the long run,” we're talking about recouping the money within a few
weeks (depending on the size of your team), not months or years. In
addition, you'll receive the quality benefit of a repeatable build process
that provides the capability to release working software
at any point in
time
(based on your business needs).
“Our software is too complex; we have to do things manu-
ally” or “No—we have all sorts of stuff going on.”
This is the perfect reason to create a CI system, because you are prob-
ably spending too much time performing redundant processes. If your
software is complex and has many dependencies, there is even more
incentive to create a system that puts all the pieces together and runs a
suite of tests and inspections to ensure everything is working correctly
and
continuously.
This is not to say that it will be easy for you to create
a repeatable build process. In fact, the larger the development infra-
structure, the more time it'll probably take to create this build system.
But creating a build system is easy if you think of the process as a
series of small steps. First, clean up the directory structure for the ver-
sion control repository so that source code, test code, configuration
files, and anything else needed is easily available. Next, use your build
scripting tool to create a simple build script that just compiles the
source code. Then add tests and inspections. Try to evolve the build
over time rather than throwing everything in at one time. As a matter
of fact, that is how we've brought about most of our CI systems. As
you get the rewards of the first few steps, you are definitely motivated
to carry on more. Work seems to go more smoothly following the
“write a little, test a little” scenario.
“Our software uses a version control repository, but we
need to support multiple versions using branching. How
will this work?”
This is an important point.
CI is run against the mainline
(head/trunk).
You must ensure that this mainline is stable at
all
times. Development
teams can become distributed or disjointed supporting various efforts,
which makes communication more difficult. There are good reasons to
create branches, but changes must be brought back to the mainline.
