Service Delivery: The Build Phase - The Practice of Cloud System Administration - page 203

currently use—source code repository software, compilers and other build tools—and of-
fers support for all your operating systems and platforms. Such tools generally can be ex-
tended through a plug-in mechanism. This way you are not at the whim of the vendor to
extend it. If there is a community of open source developers who maintain freely available
plug-ins, that is a good sign. It usually means that the tool is extensible and well main-
tained.
A build console also should have an API for controlling it. You will want to be able to
write tools that interact with it, kick off jobs, query it, and so on. One of the most simple
and useful APIs is an RSS feed of recently completed builds. Many other systems can read
RSS feeds.
Case Study: RSS Feeds of Build Status
StackExchange has an internal chat room system. It has the ability to monitor an
RSSfeedandannounceanynewentriesinagivenroom.TheSREchatroommon-
itors an RSS feed of build completions. Every time a build completes, there is an
announcement of what was built and whether it was successful, plus a link to the
status page. This way the entire team has visibility to their builds.
9.5 Continuous Integration
Continuous integration (CI) is the practice of doing the build phase many times a day in an
automated fashion. Each run of the build phase is triggered by some event, usually a code
commit. All the build-phase steps then run in a fully automated fashion.
All builds are done from the main trunk of the source code repository. All developers
contributecodedirectlytothetrunk.Therearenolong-livedbranchesorindependentwork
areas, created for feature development.
Theterm“continuous”referstothefactthateverychangeistested.Imagineagraphde-
pictingwhichchangesweretested.InCI,thelineisunbroken—thatis,continuous.Inother
methodologies, not every release is tested and the line would be broken or discontinuous.
The benefit of triggering the build process automatically instead of via a manual trigger
is not just that no one has to stand around starting the process. Because the process is
triggered for each code commit, errors and bad code are discovered shortly thereafter. In
turn, problems are easier to find because of the “small batches” principle discussed in Sec-
tion 8.2.4 , and they are easier to fix because the context of the change is still in the deve-
loper's short-term memory. There is also less of a chance that new changes will be made
on top of buggy code; such changes may need to be reversed and reengineered, wasting
everyone's time.