我还可以生动记起第一次看到大型软件工程的情景。我当时在一家大型英国电子公司的QA部门实习。我的经理带我熟悉公司环境，我们进到一间巨大的，充满了压抑感和格子间的的仓库。我被告知这个项目已经开发了好几年，现在正在集成阶段，并已经集成了好几个月。我的向导还告诉我没人知道集成要多久才能结束。从此我学到了软件开发的一个惯例：集成是一个很耗时并难以预测的过程。但是事实并非总是如此，我的 ThoughWorks 同事所做的项目，以及很多其它遍布世界各地的软件项目，都不会把集成当回事。任何一个开发者本地的代码和项目共享基准代码的差别仅仅只有几小时的工作而已，而且这只要几分钟的时间就可以被集成回去。任何集成错误都可以很快被发现，并被快速修复。这鲜明的差别并非源于昂贵和复杂的工具。其中的精华蕴含于一个简单的实践：使用统一的代码仓库并频繁集成（通常每天一次）。
当我向别人介绍持续集成方法时，人们通常会有两种反应：“这（在我们这儿）不管用”和“做了也不可能有什么不同”。但如果他们真的试过了，就会发现持续集成其实比听起来要简单，并且能给开发过程带来巨大的改变。因此第三种常见的反应是：“我们就是这么做的，做开发怎可能不用它呢？”
“持续集成”一词来源于极限编程（Extreme Programming），作为它的12个实践之一出现。当我开始在 ThoughWorks 开始顾问职业生涯时，我鼓励我所参与的项目使用这种技巧。Matthew Foemmel 将我抽象的指导思想转化为具体的行动。我们看到了项目从少而繁杂的集成进步到我所描述的不当回事。Metthew和我将我们的经验写进了这篇论文的第一版里。这篇论文后来成了我网站里最受欢迎的文章之一。
尽管持续集成不需要什么特别的工具，我们发现使用一个持续集成服务器软件还是很有效果的。最出名的持续集成服务器软件是 CruiseControl，这是一个开源工具，最早由 ThoughWorks 的几个人开发，现在由社区维护。之后还有许多其他持续集成服务器软件出现，有些是开源的，有些则是商业软件，比如 ThoughtWorks Studio 的 Cruise。