持续集成部署

前期对于推送的UI自动化已经实现了半自动化，当前做的工作就是彻底摆脱人力，实现全自动化，就是现在正在做的持续集成。在做好此项部署后，我们的推送UI自动化测试才算是圆满完成。

目的：在相应的运行环境下对相应的客户端进行测试。共创建2个Jenkins任务即可：

Android   iOS

PUB         PUB(测试环境)

PROD      PROD（正式环境）

运行流程：定时触发构建--选择运行环境—从git下载源码—在shell脚本中修改配置文件—运行python脚本。

1、       定时触发构建：

为了实现对推送的监控，不用每次都认为的去构建任务，我们需要给此任务加一个定时触发机制，如：每周一早上8点触发构建，H 8 * * 1。

2、       选择运行环境：

运行环境的选择是根据选项参数来控制，当构建任务时，选择PUB或PROD就可以运行对应的用例，仅一个任务就可以覆盖2种环境，资源利用率和灵活性都很高。

3、       从git下载源码：

测试用的配置文件，存放case的jar包，python脚本及log文件都存放在git上。每次构建任务时，会从git上去拉最新的代码，保证我们测试脚本及用例都是最新的，灵活的。只需将我们git地址及有权限的用户填入对应项即可，若出现错误，首先要考虑Credentials是否对此git任务有权限。

4、       在shell脚本中修改配置文件：

因为我们的配置文件都是从git上下载下来的，里面内容的关键信息可能跟要运行的case不符。如：配置文件中的PUSHENV是PROD，但是我们想要做QA环境下的测试，就需要对这个字段进行修改。

5、       运行python脚本：

这一步就很简单啦，前提准备都做好了，直接运行python脚本就可以完成case的测试，log的分析及邮件的发送，python脚本就是测试的核心。

整体的流程介绍完了，接下来总结一下实现过程中遇到的问题及解决办法吧，把自己的经验记录一下也供小伙伴参考：

1、  本机安装Jenkins，进行调试

在实现持续集成的过程中，少不了要对自己所做的部分进行调试，这就需要在本机安装一个Jenkins。有一个简单的方法：前往https://jenkins.io/download/，下载Generic Java package (.war)。然后进入war包所在目录下，命令行执行 java -jar jenkins.war即可开启Jenkins，并且，本机配置的环境都再次适用，很方便。

2、  apk卸载、下载及安装：

为了保证每次测试的都是最新的安装包，在测试之前我们会对设备已有安装包进行卸载，然后在Jenkins上下载最新安装包并安装。但问题来了，如果想针对设备上已有的某一安装包进行测试怎么办？当然是略过这一步骤啦。所以用了给python脚本传参的方式，即：Y重装，N不重装。

3、  删除工作空间的安装包

经过上面的步骤后会发现workspace中存在一个apk，在第二次下载安装包后，新下载的安装包的名称为apk.1，但是我们安装的还是apk。也就是说此次安装的还是以前的包，并不上本次下载的新包。所以，我们需要在每次运行结束后将本次下载的安装包从空间里删除。

4、  邮箱收件人改为可配置

之前邮件的收件人是在python脚本中写死的，也就是要想修改收件人必须要去修改脚本，这样的灵活性和易用性太差了。所以，改用传参的方式，将收件人作为一个字符参数，可以在运行程序前任意更改。

5、  配置文件、case所在jar包存放路径可配置：

此问题出现在，Jenkins做持续集成运行程序的时候，配置文件在workspace中，但在本机运行时配置文件放在本机用户目录下的一个固定文件夹中。也就是说，我们既要保证持续集成的运行，也要保证在本地的运行。同样，采用传参的方式，在Jenkins中运行时给python传入workspace路径，在本地时传入本地配置文件所在路径。Case所在jar同理。当然了，一定不能忘了对jar包中读取配置文件的逻辑进行修改。同样，采用给jar包传参的方式，当在Jenkins中运行时读取workspace中的配置文件，在本地时读取本地配置文件。

未完待续…