文/秋之川
这是《落叶》文集里第 340 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【提问】
做到什么样才算是真正的持续集成？
【旧识】
我本以为只要做到单元测试、每日集成和每日构建，就算是持续集成了。
- 开发工程师完成单元测试，提交代码至代码库；
- 开发工程师根据测试需求或项目计划，手工编译、打包各个组件包；
- 开发工程师在测试环境的相关服务器上部署不同的组件包；
- 开发工程师检查所有服务是否可以正常启动；
- 测试工程师执行 BVT 测试，确保基本功能正常；
- 测试工程师开始验证修复的缺陷，做回归测试和功能需求测试；
即使玩转了这个流程，也是存在一些问题的：
- 步骤1~4所需时间较长，还不包括中途出了问题，联调排查所耗费的时间；
- 步骤1~4需要等待开发工程师执行，在成功完成之前，测试工程师都处于等待状态；
- 步骤5如果发现 Block Issue，测试无法进行下去，还得重复步骤1~4，测试工程师又需要等待；
- 通常问题都是产生在第一天，而到第二天才会被发现，而且这些等待所消耗掉的时间都是宝贵的工作时间；
【新知】
要想解决存在的问题，就需要做到真正的持续集成（Continuous Integration, CI），从问题本身来看解决方案，其实就是在测试工程师第二天上班开始验证 bug 和开始测试工作之前，就把最新的、没有问题的、可测的版本包部署到测试服务器。
- 开发工程师提交代码至代码库，定时触发或事件触发自动完成单元测试和代码检查；
- 系统自动构建相应的组件包，定时触发或事件触发编译和打包动作；
- 在测试环境的相关服务器上自动部署相应的组件包；
- 部署完成后，自动执行 BVT 测试脚本；
- 自动发送部署结果和 BVT 测试结果；
- 单元测试、代码检查、编译、构建、部署和测试过程中的任何一个 block 问题都会自动报警，并通知相关工程师及时处理；
- 步骤1~6都可以通过 cron job 定时在下班后开始执行；
持续集成只是技术手段上的改进和优化，为了达到最终的目的，也就是持续交付（Continuous Delivery, CD），还有很多思想层面和工作方法方面需要提升。
我一直认为引入持续集成的难点在于重构的成本，你要想引入持续集成，你的代码结构可能需要重构、环境架构可能需要调整、你的自动化测试脚本更新速度要能跟的上持续集成的节奏。
这一切都需要投入一定的人力和物力，而且这些还都需要在项目进行的过程中，安静、有序、无害地被完成，因为项目的成本或工期制约，通常很难有一段完整的空档期去完成持续集成的引入和部署，所以，这个风险需要在项目初期考虑进去，尽量选择内部研发的项目进行试点推行。
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
