这是《落叶》文集里第 339 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【提问】
原来这就是持续集成啊？
【旧识】
很多年前在做项目的时候，其实就已经接触到了持续集成，只是那时候好像没有这么一种叫法，或者说也没现在处于互联网产品时代的这么火热，所以，有相当长的一段时间，一直认为持续集成是个新生事物，自己一直都没有接触过它，很神秘。
那时候只是很简单的目的，为了方便、快速地生成可部署、可测试的包。
这不就是自动构建吗？
那时候，项目开始的时候，就会建立一个新的 branch，开发写完某个功能，或者修复完一个 bug，就将 code check-in 到对应的版本分支里，根据开发和测试的计划，大概在代码集成阶段就会在一个 web 端的 build 系统里去创建 Daily Build Job，每天在中国时间的凌晨开始，系统自动检测 svn 里对应分支是否有代码更新，并从中 check-out 最新的 code，然后构建成 build。如果构建出错了，会生成 build failed log，能通过日子定位到相关的代码和开发工程师。测试工程师早上来上班第一件事，就是从 build server 上下载最新的 build，然后部署，开始一天的测试工作。
这不就是自动部署吗？
后来，测试工程师为了提升工作效率，想让自己一到办公室就可以开始测试，于是基于这个 Auto Build 系统，又开发了 Auto Deployment 脚本，自动检测是否有最新的包，有的话就去下载并自动安装。
这不就是自动验证吗？
再后来，测试工程师为了再次提升工作价值，让自己每天聚焦在更有意义的 bug 深度挖掘工作上，又将 BVT Automation 集成了进去，当自动部署完成之后，自动执行 BVT TA 脚本，用于检测最新的构建包是否存在一些很浅显的和阻碍性的缺陷。
最近，因为越来越多的同学会问到持续集成的问题，所以找了一些书和资料，学习了一下，然后问了自己一个问题：原来这就是持续集成啊？
【新知】
这几年持续集成的兴起，并不是因为测试工程师越来越“懒”，而是随着互联网产品的运营模式和敏捷研发的广泛应用，提升研发团队持续交付能力的一个很重要的技术越来越受用，那就是持续集成。
我们先来看看引入持续集成的好处：
- 随着项目越来越大，越来越复杂，每天各种各样的开发工程师都在 check-in 代码，如何能快速发现其中会导致构建失败的错误代码呢？-- 持续集成。
- 随着研发速度越来越敏捷，测试工程师可能随时都需要一个可测的版本去验证 bug，做回归测试，而不能等待所有的开发都提交了最新的、完整的代码，再打一个没问题的测试包，那怎么办呢？-- 持续集成。
- 产品也需要经常拿一个可用的、最新的版本去体验最新的功能，去验收已经完成的需求，他可以找谁呢？-- 持续集成。
- 每日构建其实是一个重复性的活动，但又需要人每天去做这么一件事情，在它完成之前，大家都得等着，假如测试人员来的很早，那负责每日构建的人就要来的更早，怎样才能既减少人力的重复劳动，又能提高效率呢？-- 持续集成
- 我们现在有很多自动化测试工具、静态扫描工具和性能测试工具，那怎样才能让它们在有限的测试周期中发挥及时、有效的作用呢？-- 持续集成
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
