我是09年07月加入国际站测试部，那时候已经有了公司自己的自动化框架Pwatir，将以前QTP脚本全部迁移过来。对自动化脚本的重复使用基本上只在全网回归中。那时候一周三个发布日，两天发小需求，发项目。发布当天将发布分支代码部署到一个回归环境，然后运行我们所有的自动化脚本（不出问题2小时，出了问题N小时），通过了发布，通过不了回滚。发布日有专职的自动化回归人员值班，负责环境部署和脚本执行。他在群里一吼回归自动化过，皆大欢喜，开始发布；他吼有问题过不了，大家一起回滚，当天发布失败。每个发布日都是一个苦逼的日子，发布的每个环节都很费时，上午各个开发将自己小需求代码合并到发布分支，下午等待自动化回归，晚上预发布和正式发布验证，基本上每个发布日都像上战场，大家都身心疲惫，搞不好发布失败，大家又去挤下一个发布日。

　　为了解决发布效率问题，开始优化各个环节，自己负责了预发布自动化值班。那时知识有限，只能写一些脚本取代手工来自动化完成各个工作，比如环境部署，脚本触发，报告发送等。为了加快执行，还到处找执行机虚拟化软件，然后虚拟机调优。后来顺畅多了，全网回归从环境部署到执行完一般1小时内搞定，被抽去边测项目边值班了。

　　10年过年后，参与了一个较大的技术项目，从设计评审开始介入（技术项目无业务需求评审），主要是想推进开发写单元测试，开发不想写，我们协助帮开发写写单元测试。结果还真能发现比较多的问题，有一些sqlmap写错的问题，大部分还是开发写好一个底层方法后，随着上层调用场景越来越多改来改去改出来的问题。当时为了能持续的运行单元测试，自己部署了一个Hudson然后把项目的开发分支监控起来，用antx test去构建（那时候还没转maven），算是第一次实践。在这个项目中，由于自己一直在全网回归值班，所以也想将自动化脚本在自己项目中用用，但是项目环境和回归环境是独立的，所以等全网回归运行结束后，建了一个Hudson任务将项目代码部署到回归环境然后运行脚本，作为一个项目测试的辅助。

　　11年出了一个非常好用的系统，那是Aone，开发合并代码不再那么痛苦了，但全网回归还是那么痛苦，各种环境问题，各种脚本问题，各种执行机问题，每个发布日都压在一个回归点上，引发了开发老大的强烈不满，影响发布效率。于是我们想到尽量将一些测试独立应用的用例在项目中提前运行掉，预发布时只需要运行一些较大的联调用例即可。项目中如何定时运行，我们还是想到了Hudson，通过调用Hudson API，一个项目小需求需要到我们系统里的表单填一下Hosts绑定，选择一下你需要运行的自动化模块，自动创建一个Hudson任务定时运行看结果了，很简单的思路用了一段时间，测试用用还是能提效不少。后来大部门测试架构组出来做了一个CIC持续集成系统，由于使用复杂，配置过多，还是自己的一些小平台靠谱。

　　12年我们发现开发单元测试已经有所好转，每个业务产品线基本上都是测试先介入慢慢推，然后老大层面也看重这个质量。代码Bug一般有纯代码问题，业务问题等。单元测试是过滤纯代码问题的，神马变量写错啊，sqlmap写错啊，代码漏写或者写错啊，代码合并解决冲突搞错啊等，让测试用一系列严谨的测试用例来发现真的不值。应该测试更关注业务联调，特殊异常，安全漏洞等。接口，UI自动化脚本等当作项目测试的辅助。12年初于是开始将我们自己的小平台扩大起来，做了一个Amon和Aone打通，先把项目的单元测试结果实时反馈到项目相关人员，先试点在扩大，开发反馈还不错，因为不需要开发做任何操作，CI代码能得到结果，何乐而不为。于是我们乘热打铁，将接口自动化，UI自动化配合着环境自动部署一并搞上去，形成了现在项目小需求持续集成的情况。现在我们的发布效率，周一到周四，项目小需求基本上是随到随发（发布区块模式），项目测试，项目集成回归加自动化回归把关。

　　说的比较粗，分享的是一个过程，具体的话每个小系统都有它背后一连串的故事。后讲讲现有我们一个项目的持续集成实践：

开发过程：Aone创建项目=>开发拉分支=>开发提交代码=>开发提交发布=>正式发布

|                            |                            |

Amon自动匹配创建集成任务=>单元测试任务反馈结果    全网回归

|

一键自动部署环境

|

UI自动化，接口自动化任务反馈结果

　　这么简单，前面与SCM系统打通，后面是围绕着开发拉分支和提交代码后来展开，系统并不复杂，更多持续集成的专项问题，我们交给其他子系统和测试框架来完成。

　　接下来在做的是提交代码前如何检查，发现开发很喜欢将提交代码变成让SVN保存代码，结果每次提交的代码质量不佳；化的自动化匹配，减少多余自动化集成的运行等等。不是很会写正式东西，当随笔写了。