Paul M.Duvall是Stelligent公司的CTO。Stelligent公司是一家咨询公司，通过优化软件开发过程，帮助开发团队可靠地、快速地开发出更好的软件。他基本上担任过软件开发项目中的所有职务，从开发者到测试者再到架构师和项目经理。他写过很多书，经常在http://testearly.com上写日志。

    《持续集成：软件质量改进和风险降低之道》全面深入地讨论持续集成的各个方面。本书介绍了一种增加项目可见性、降低项目失败风险的有效实践。许多软件开发的资深人士认定，这种方法非常不错。本书除了介绍持续集成的基本原则和工具之外，也介绍了测试驱动、代码审查、数据库集成、信息反馈等实践和工具。书中的各种主题介绍了今天在持续集成领域中运用的各种方法，帮助读者衡量需要进行的折衷。

    译者序<br>    Martion Fowler序<br>    Paul Julius序<br>    前言<br>    作者简介<br>    贡献者简介<br>    第一部分　CI的背景知识：原则与实践<br>    第1章　启程<br>    1.1 针对每次变更构建软件<br>    开发人员<br>    版本控制库<br>    CI服务器<br>    构建脚本<br>    反馈机制<br>    集成构建计算机<br>    1.2　CI的特征<br>    源代码编译<br>    数据库集成<br>    测试<br>    审查<br>    部署<br>    文档与反馈<br>    1.3　本章小结<br>    1.4　问题<br>    <br>    第2章　引入持续集成<br>    2.1　CI生活中的一天<br>    2.2　CI的价值是什么<br>    减少风险<br>    减少重复过程<br>    生成可部署的软件<br>    增强项目的可见性<br>    建立起更强大的产品信心<br>    2.3　什么阻碍了团队使用CI<br>    2.4　如何进行“持续”集成<br>    2.5　项目应该在何时以何种方式实现CI<br>    2.6　集成的演进<br>    2.7　CI如何与其他开发实践配合<br>    2.8　CI需要多少时间架设<br>    2.9　CI与您<br>    2.10　经常提交代码<br>    2.11　不要提交无法构建的代码<br>    2.12　立即修复无法集成的构建<br>    2.13　编写自动化的开发者测试<br>    2.14　必须通过所有测试和审查<br>    2.15　执行私有构建<br>    2.16　避免签出无法构建的代码<br>    2.17　本章小结<br>    2.18　问题<br>    <br>    第3章　利用CI减少风险<br>    3.1　风险：没有可部署的软件<br>    场景：“在我的机器上是行的”<br>    场景：与数据库同步<br>    场景：点错了<br>    3.2　风险：很晚才发现缺陷<br>    场景：回归测试<br>    场景：测试覆盖<br>    3.3　风险：缺少项目可见性<br>    场景：“您收到了备忘录吗？”<br>    场景：不能使软件可见<br>    3.4 风险：低品质的软件<br>    场景：坚持编码标准<br>    场景：维持架构<br>    场景：重复的代码<br>    3.5　本章小结<br>    3.6 问题<br>    第4章　针对每次变更构建软件<br>    <br>    第二部分 创建全功能的CI系统<br>    第5章　持续数据库集成<br>    第6章　持续测试<br>    第7章　持续审查<br>    第8章　持续部署<br>    第9章　持续反馈<br>    尾声　CI的未来<br>    附录A　CI资源<br>    附录B　评估CI工具<br>    参考文献