自动化功能测试实践五：Jenkins持续集成1

         之前和同行的朋友沟通过持续集成，项目中配置管理组也提供了Jenkins为我们测试编译源代码。但是终究是受周围环境的影响，没有去真正实践过，就是处在一种不知道自己不知道什么的状态（其实也可以通过多读书来破的）。

        值得我自己庆幸的是，最近几次出去面试，都有谈到jenkins的问题。这时我才真正重视起来。

        持续集成的过程，可以理解成开发提交版本后，触发jenkins自动编译并发布编译结果邮件，同时触发自动化脚本回归测试该版本是否影响了已有功能。

        持续集成的思路包括如下几方面：

第一，  自动编译，并发布编译结果邮件（邮件中带编译过程的页面链接地址）给代码提交人，测试相关人员和开发负责人。这样就达到一个管理目的，谁提交代码谁负责。之前开发提交代码就不管了，测试编译不过跑好几趟都解决不了问题，碰到开发环境和测试环境不一致时，开发死不承认自己的包有问题。

当然，想达到这个管理目的还要作如下几件事：

1、公开同开发团队的沟通，让他们理解这个自动编译的过程。这可以发邮件或者在QQ群里沟通，保证项目相关人员都会看到。

2、告诉他们邮件会发给开发负责人，同时也单独跟开发负责人进行良好沟通。

3、确认前几次代码提交后自动编译过程无误。

有了这些保障后，开发人员就会主动配合，有问题还主动来沟通。

第二， 编译完成后，替换运行环境文件，并重启服务。这个过程要连接应用服务器，并编写shell命令。

第三，  编译job关联一个robotframework脚本的job，编译完成后，触发自动化脚本自动运行，并发布测试结果邮件。这个过程之前是手动触发的，现在遇到自动化脚本文件路径中有中文的问题（设计结构的时候的无知），jenkins不能识别，导致部分脚本还没有完全达到我的目的。现在涉及到调整比较多，后期会持续解决这个问题。同时也是血的教训，建议大家的脚本不要使用中文名字。

下一次再抽时间和大家分享持续集成的过程。敬请期待。。。