“当一个项目经理或一名开发者说已经完成了80%的任务，您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间，甚至永远都不能完成。”

上面这段话来自于《持续集成——软件质量改进和风险降低之道》的译者序。仔细想想，此话说得相当有道理：程序员是一群自信而乐观的人，总是以为自己已经考虑到了方方面面，所编写的模块万无一失、无懈可击。哪怕遇到了问题，也总会找到理由：是不是需求或是别人出了问题——一句最为流行的Developer应对Tester的Bug Report的话就是，“It is not a bug, but it is a feature.”。

不过即使程序员有千万种理由为自己的模块洗清了一切的“罪名”，但客户需要的上线或发布时间却仍旧无声地等在那里，不以任何人的借口而改变。

回到本文开始的那段译者序文字中，那“剩下的20%”究竟要用来做什么呢？为什么“可能还需要80%的时间”呢？

答案就是集成。虽然流行的软件开发理论已经把模块/组件之间的耦合程度降低到了最低，且有无数种类似单元测试的“流程”保证这每一个独立模块功能的正确性，不过当把这些堪称“完美”的模块集合成一个整体系统时，还是会不停地出现各种问题？

OK，让我们停止探讨为什么会发生这样的情况之类无谓的探讨，而是去看看应该怎样解决这个问题，并最终保证产品的发布时间和质量——毕竟问题已经发生了。

——持续集成。

持续集成能够把最终的一次大规模的集成调试过程分散到项目开发时间表的每一周、每一天、甚至每个小时。让项目中的各个人员都能够随时掌握当前的整体进度，并迅速发现集成过程中出现的问题并进行解决。

这本《持续集成——软件质量改进和风险降低之道》的第一部分就详细介绍了持续集成的理念、相关流程以及做法。

目前来看，持续集成似乎看起来非常不错，不是吗？

可是，一次集成并不是说句话就能搞定的——构建、部署、测试、生成测试报告、反馈……种种操作将会占用大量的人工。难道还需要专门派人负责每天的集成吗？

因此，将所有的步骤自动化，就是实现持续集成中最为重要的问题。

《持续集成——软件质量改进和风险降低之道》的第二部分则给出了一个完善的自动化持续集成流程，让持续集成从一句空谈变为实实在在的、具有可操作性的规范。

不过是一本200页左右的小书，却已经毫无遗漏地将持续集成的点点滴滴娓娓道来。若你正在为这方面的问题苦恼，不妨尝试从中找到一些答案。