http://d.hatena.ne.jp/keyword/%B7%D1%C2%B3%C5%AA%A5%A4%A5%F3%A5%C6%A5%B0%A5%EC%A1%BC%A5%B7%A5%E7%A5%F3

継続的インテグレーションとは、ソフトウェアの品質改善・納期短縮のための
ソフトウェア・エンジニアリングの習慣の集合である。その原則は、
開発の連続的な全行程が終わってから品質管理を行うという古い慣行をやめ、
成果物の諸小部分に対して頻繁に品質管理を行うことである。

理論

修正に着手するとき、開発者は動いている現在のリポジトリのコピーをローカルに取る。
修正されたコードが他の開発者によってリポジトリにコミットされた場合、
このローカルのコピーは徐々にリポジトリのコードを反映しなくなっていく。
開発者がリポジトリにコードをコミットする時、彼らは、まず、リポジトリ内の
修正をローカルのコードに反映させるために、自らのローカルのコードを
最新のものにしなければならない。リポジトリ内の修正が多ければ多いほど、
より多くの仕事を開発者は自らの修正をコミットする前に行わなければならない。

そのうち、リポジトリは開発者のローカルのコピーとはあまりにかけ離れた物になり、
彼らは統合地獄（integration hell）*1と呼ばれる状態に陥る。最悪の場合、開発者による修正を放棄し、仕事をやり直すことになる。

継続的インテグレーションは、"統合地獄"という陥穽を避けるために、統合を早期に、
頻繁に行う習慣である。究極の目標はやり直しを減らす。それによって経費を減らし、納期を短縮する。