Martin在第二版中则在成功构建的基础上给出了成功集成的定义。成功集成关注的不是一次“编译+链接+部署+验证”的过程，而是从开发流程的角度介绍一次完整的在持续集成约束下的代码提交过程4：

　　将已集成的源代码复制一份到本地计算机。

　　修改产品代码和添加修改自动化测试。

　　在自己的计算机上启动一个自动化构建。

　　构建成功后，把别人的修改更新到我的工作拷贝中。

　　再重新做构建。

　　把修改提交到源码仓库。

　　在集成计算机上并基于主线的代码再做一次构建。

　　只有这次构建成功了，才说明改动被成功的集成了。

　　下图展示了Martin对成功集成的定义：

　　当然在第一版的“代码提交”这一节，Martin也提到了本地构建的概念，只是不如第二版这么明确。

　　2) 配置管理

　　Martin在第一版中有两处提及配置管理，分别是：单一代码源(Single Source Point)和代码提交(Checking In)。第二版中则包括：通过持续集成构建特性(Building a Feature with Continuous Integration)、只维护一个代码仓库(Maintain a Single Source Repository)、每人每天都要向主线提交代码(Everyone Commits To The Mainline Every day)、每次提交都应在集成计算机上重新构建主线(Every Commit Should Build the Mainline on an Integration Machine)。不仅条目数量上增加明显，作者提出的很多实践都是基于配置管理来讲的。

　　工具

　　配置管理是持续集成的输入。在第一版中作者所推荐的配置管理工具是CVS，到第二版中作者推荐的配置管理工具已经换成了SVN5(参见第二部分中的配置管理工具部分)。

　　分支策略

　　实现进度与质量的平衡是配置管理的重要目的。Martin在第二版中对滥用分支给出了警告：

　　尽量减少分支数量。典型的情况是保持一条主线，……，每个人都从这条主线开始自己的工作。(对之前发布版本进行Bug修正或者临时性的实验都是创建分支的正当理由。)

　　但是这里给出的建议对于大型团队来说并不十分合适。我们将在第二部分对于配置管理的分支策略进行详细描述。

　　内容

　　Martin在第一版中给出的原则是：

　　任何人都可以找到一台干净的机器，连上网，通过一个命令可以取得要构建所开发的系统需要的所有源文件。

　　第二版中的原则增加了对构建的支持6：

　　任何人都可以找到一台干净的机器，做一次取出(checkout)动作，然后对系统执行一次完整的构建。