其实从进入测试这一行来,就已经接触到了持续集成,那时候的持续集成好像就是简单的:
为了方便、快速地生成可部署、可测试的包。
所以现在想想这不就是自动构建吗?
小公司的项目开始的时候,就会建立一个新的 branch,开发写完某个功能,或者修复完一个 bug,就将对应的功能添加到对应的版本分支里,根据开发和测试的计划,会在每天的早上构建一个最新的测试包,那么持续集成做的就是自动构建,去git上拉取代码然后自动打包成可以测试的包。如果构建出错了,会生成 build failed log,能通过日期定位到相关的代码和开发工程师。测试工程师早上来上班第一件事,就是从 build server 上下载最新的 build,然后部署,开始一天的测试工作。
这不就是自动部署吗?
后来,测试工程师为了提升工作效率,想让自己一到办公室就可以开始测试,于是基于这个 Auto Build 系统,又开发了 Auto Deployment 脚本,自动检测是否有最新的包,有的话就去下载并自动安装。
这不就是自动验证吗?
再后来,测试工程师为了再次提升工作价值,让自己每天聚焦在更有意义的 bug 深度挖掘工作上,又将 自动化测试集成进去,当自动部署完成之后,自动执行 自动化测试的 脚本,比如python接口自动化测试,app自动化测试,用于回归、冒烟测试最新的构建包是否存在一些很浅显的和阻碍性的缺陷。
最近,因为越来越多的同学会问到持续集成的问题,所以找了一些书和资料,学习了一下,然后问了自己一个问题:原来这就是持续集成啊?
【新知】
这几年持续集成的兴起,并不是因为测试工程师越来越“懒”,而是随着互联网产品的运营模式和敏捷研发的广泛应用,提升研发团队持续交付能力的一个很重要的技术越来越受用,那就是持续集成。
我们先来看看引入持续集成的好处:
- 随着项目越来越大,越来越复杂,每天各种各样的开发工程师都在 check-in 代码,如何能快速发现其中会导致构建失败的错误代码呢?-- 持续集成。
- 随着研发速度越来越敏捷,测试工程师可能随时都需要一个可测的版本去验证 bug,做回归测试,而不能等待所有的开发都提交了最新的、完整的代码,再打一个没问题的测试包,那怎么办呢?-- 持续集成。
- 产品也需要经常拿一个可用的、最新的版本去体验最新的功能,去验收已经完成的需求,他可以找谁呢?-- 持续集成。
- 每日构建其实是一个重复性的活动,但又需要人每天去做这么一件事情,在它完成之前,大家都得等着,假如测试人员来的很早,那负责每日构建的人就要来的更早,怎样才能既减少人力的重复劳动,又能提高效率呢?-- 持续集成
- 我们现在有很多自动化测试工具、静态扫描工具和性能测试工具,那怎样才能让它们在有限的测试周期中发挥及时、有效的作用呢?-- 持续集成
持续集成还可以干更多的事情,当然不仅仅是测试,开发自动化运维,代码灰度发布验证,等等复杂的功能。