理论上来说，持续集成听起来很好。它不需要依赖冗长乏味的瀑布流程，可以在任何时段都可以阻止灾难项目的失败，同时，企业可以采用更加模块化、灵活化的方式开发新软件。任何一段程序通过了测试要求，我们就可以部署整个程序。数月或者数年后，仍然会有已完成的项目无法按照预期的那样在市场上发布。当然了，我们可以将关注度放在功能和流程上，采用这种更有机的方式来开发新软件。

然而，我们并不能非常自然地就过渡到持续集成中。这是因为，我们还需要检查代码中是否存在漏洞，同时，也应该监测CI过程本身是否有效。作为《Jenkins: The Definitive Guide》的作者，John Smart为我们提供了四条有价值的信息：

#1持续集成中仍然需要大量的人工流程吗？

真正的持续集成是要实现尽可能多的自动化流程。我们要对仍然需要人工操作的流程进行检查。如果在开发、测试或者实施阶段，系统管理员还需要被迫运行各种脚本，那么就表明，这种持续集成还有很大的改进空间。要想实现100%自动化也许不太可能，而且也存在很大的风险。但是，我们应该将这种接近全自动化的要求作为我们应该实现的一个目标。

#2 持续集成的输出内容要达到什么样的标准？

我们不应该只是报导所完成任务的表象。要通过严格的检查去报导和衡量哪些方面可能陷入困难，或者哪些地方还没有达到接受的标准。同时，我们还要对比CI项目与之前项目的差别，从而确定需要改善的地方。这些也许是最简单的改善，更重要的是，我们应该从持续集成中获得一些附加价值。最起码，要关注“信息辐射体”。通常，所有系统都是这样运行的吗？

#3可接受的标准都实现了吗？

一开始创建接受标准的时候，这些标准就决定了整个项目的设计和编码基础。但是，如果该标准文件没有被纳入到系统之中，那么，整个项目就很容易偏离最初的设计。接受标准应该自动成为测试的一部分，而且应该是一种“活文档”。这样，在整个CI过程中，我们都可以更新接受标准，而且会使该标准总是非常精确。报告和火文档就像硬币的正反两面，都可以向开发项目的利益相关者说明此次代码的编写是符合要求的。要记住，单位测试不应该像技术资料那样让人难以理解。

#4部署可以立即实施吗？

持续集成的整体目标是推动项目的进程。成功实施项目所花费的时间是衡量组织转向CI的一个重要进程指标。全自动化CI通过在几分钟内就可以完成任务。即使是部分自动化CI过程也会在几个小时内就完成任务。如果需要花费几天的时间才能实现新功能，那么一定是在转换过程中出现了什么错误。这种结论也适用于经常出现回滚的现象。当然，我们应该在系统的某些地方保留旧版本，在必要的情况下，恢复到以前的旧版本进行工作。然而，我们应该对持续集成有信心，因为，该测试绝对能确保项目顺利实施。

您有哪些与CI类似的经验吗？可以告诉我们！