其实从进入测试这一行来，就已经接触到了持续集成，那时候的持续集成好像就是简单的：
为了方便、快速地生成可部署、可测试的包。

所以现在想想这不就是自动构建吗？
小公司的项目开始的时候，就会建立一个新的 branch，开发写完某个功能，或者修复完一个 bug，就将对应的功能添加到对应的版本分支里，根据开发和测试的计划，会在每天的早上构建一个最新的测试包，那么持续集成做的就是自动构建，去git上拉取代码然后自动打包成可以测试的包。如果构建出错了，会生成 build failed log，能通过日期定位到相关的代码和开发工程师。测试工程师早上来上班第一件事，就是从 build server 上下载最新的 build，然后部署，开始一天的测试工作。
这不就是自动部署吗？
后来，测试工程师为了提升工作效率，想让自己一到办公室就可以开始测试，于是基于这个 Auto Build 系统，又开发了 Auto Deployment 脚本，自动检测是否有最新的包，有的话就去下载并自动安装。
这不就是自动验证吗？
再后来，测试工程师为了再次提升工作价值，让自己每天聚焦在更有意义的 bug 深度挖掘工作上，又将 自动化测试集成进去，当自动部署完成之后，自动执行 自动化测试的 脚本，比如python接口自动化测试，app自动化测试，用于回归、冒烟测试最新的构建包是否存在一些很浅显的和阻碍性的缺陷。
最近，因为越来越多的同学会问到持续集成的问题，所以找了一些书和资料，学习了一下，然后问了自己一个问题：原来这就是持续集成啊？
【新知】
这几年持续集成的兴起，并不是因为测试工程师越来越“懒”，而是随着互联网产品的运营模式和敏捷研发的广泛应用，提升研发团队持续交付能力的一个很重要的技术越来越受用，那就是持续集成。
我们先来看看引入持续集成的好处：

1. 随着项目越来越大，越来越复杂，每天各种各样的开发工程师都在 check-in 代码，如何能快速发现其中会导致构建失败的错误代码呢？-- 持续集成。
2. 随着研发速度越来越敏捷，测试工程师可能随时都需要一个可测的版本去验证 bug，做回归测试，而不能等待所有的开发都提交了最新的、完整的代码，再打一个没问题的测试包，那怎么办呢？-- 持续集成。
3. 产品也需要经常拿一个可用的、最新的版本去体验最新的功能，去验收已经完成的需求，他可以找谁呢？-- 持续集成。
4. 每日构建其实是一个重复性的活动，但又需要人每天去做这么一件事情，在它完成之前，大家都得等着，假如测试人员来的很早，那负责每日构建的人就要来的更早，怎样才能既减少人力的重复劳动，又能提高效率呢？-- 持续集成
5. 我们现在有很多自动化测试工具、静态扫描工具和性能测试工具，那怎样才能让它们在有限的测试周期中发挥及时、有效的作用呢？-- 持续集成

持续集成还可以干更多的事情，当然不仅仅是测试，开发自动化运维，代码灰度发布验证，等等复杂的功能。