Information Technology Reference
In-Depth Information
Understanding the fundamentals of CI is quite easy, and in no time
you'll be integrating these fundamental practices of software develop-
ment into your builds.
When reading topics, I like to see an example first and then learn the
“why” behind the example afterward, as I find that an example pro-
vides a context for learning the “why.” We describe a CI scenario
based on a typical implementation. You'll find there are various ways
to implement a CI system, but this should get you started in under-
standing the parts of a typical system.
What Is a
Build
?
A
build
is much more than a compile (or its dynamic language
variations). A build may consist of the compilation, testing,
inspection, and deployment—among other things. A build acts as
the process for putting source code together and verifying that
the software works as a cohesive unit.
A CI scenario starts with the developer committing source code to
the repository. On a typical project, people in many project roles may
commit changes that trigger a CI cycle: Developers change source
code, database administrators (DBAs) change table definitions, build
and deployment teams change configuration files, interface teams
change DTD/XSD specifications, and so on.
Keeping Examples Up to Date
The risk of writing a “hands-on” example in a book is that it
quickly becomes outdated, especially with a dynamic topic like
CI. To offset changes that may occur after this topic is published,
we will update the topic's companion Web site,
www.integrate-
button.com,
with examples on not just CruiseControl and Ant, but
many other CI servers and tools as well.
