<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>DogBiscuit</title>
    <description>... mmm, crunchy!</description>
    <link>http://dogbiscuit.org/mdub/weblog</link>
    <language>en-us</language>
    <generator>EvenYetAnotherWeblog</generator>
    <item>
      <title>"Continuous Integration" might not mean what you think it means</title>
      <guid>http://dogbiscuit.org/mdub/weblog/Tech/Agile/ThePointOfContinuousIntegration</guid>
      <pubDate>Tue, 08 Jul 2008 23:25:00 +1000</pubDate>
      <description><![CDATA[<p>
<a href='http://martinfowler.com/articles/continuousIntegration.html'>Continuous
Integration</a> is a
common practice in <a href='http://agilemanifesto.org/'>Agile</a> development circles, but I
think people (especially those new to agile thinking) sometimes miss the point.
</p>
<p>
Problem is, the term has become synonymous with build-servers such as
<a href='http://cruisecontrol.sourceforge.net/'>CruiseControl</a>
(<a href='http://tinderbox.mozilla.org/'>etc</a>, <a href='https://hudson.dev.java.net/'>etc</a>), which
frequently grab the latest code, build it, and execute automated tests. These are
often referred to as "continuous-integration servers", which IMHO is a <u>really
bad name</u>, 'cos if there's one thing these servers typically <em>don't</em> do,
it's <u>integrate</u>.
</p>
<p>
And the point of continuous-integration is just that: <strong>Integrating</strong>.  <strong>Continuously</strong>!  Which means: 
</p>
<ul class="sparse">
<li>
developers frequently updating their working-areas (or personal branches) with
  the latest code on the mainline branch (typically many times a day), and
</li>
<li>
frequently merging their own changes back into the mainline (typically several
  times a day).
</li>
</ul>
<p>
Unless you're doing this, you ain't "doing continuous integration", however frequently you're running automated builds!
</p>
<p>
Integrating continuously can be difficult. In particular, it forces you to chunk
larger changes and features into small, bite-sized pieces that can be drip-fed
into the codebase. And, you have to deal with other developers changing stuff all
the time. Build-servers and automated tests are essential tools here, because they
help keep the team honest, ensuring that everyone has a stable (if evolving) base
to work on.
</p>
<p>
There are are plenty of upsides to frequent integration:
</p>
<ul>
<li>
each individual integration is smaller, and therefore easier
</li>
<li>
design issues (including differences of opinion) are identified earlier
</li>
<li>
developers can leverage each other's work earlier
</li>
<li>
changes can be tested (and bugs detected) earlier
</li>
<li>
software can be deployed more frequently
</li>
</ul>
<p>
In summary: check it in already!
</p>
]]></description>
    </item>
  </channel>
</rss>
