我所理解的持续集成( CI )：

• 即是“开发”到“部署”到“测试”的自动过程：开发每次提交的代码，代码都能够自动被拉取并和自动与其它代码集成、编译，然后部署到对应的服务器环境并启动该代码所属程序，接下来自动执行相应模块或整体的自动化测试，这个过程若有任何一步出现问题，意味着触发这次持续集成的改动是存在bug的；

• “集成”意味着任一代码改动，都是需要与其它代码、服务融合工作的，是改动体现意义的前提所在；

• “持续”意味着这个过程期望开发能够尽早、尽频地提交以触发整个CI过程，尽量把bug“扼杀”在摇篮里。

持续集成的意义：

• 尽早的发现bug：开发尽量以最小的量提交改动，每次提交，就触发整个持续集成构建过程：编译>部署>自动化测试，如果改动存在问题，那么自动化测试就会立即测试出bug。

• 尽快的定位bug位置：持续集成过程中，任一子过程不通过，那么肯定是上一个触发CI的改动引起的，从而尽快地定位到bug位置。

• 最小代价定位bug原因：缩小了bug引发范围，有助于问题的定位和对修复的持续验证，花最小代价找出bug原因。

• 当然，于测试而言，可以在一定程度上解放双手，节约时间成本，花时间去做需要我们思考的的东西。

依赖：

• 代码托管：代码必须存在于线上、才能够满足“拉取”这个动作。例如Git。

• 持续集成工具：负责整个持续集成过程的调度。常用的有Jenkins。

• 自动编译、部署脚本：受持续集成工具的“指挥”，负责具体动作的实施。

• 自动化测试服务和脚本：同样受持续集成工具的“指挥”，负责对“集成”效果的验证。

• 通知服务：这个一般存在于持续集成工具内部(插件)，负责通知CI的结果，如邮件报警。

• 版本回退配置：一次失败的集成，可能影响其它开发工程师的代码集成，考虑这种情况，需要配置版本可回退服务。

见解不同之处，望不吝赐教~