接口自动化实战之持续集成

什么是持续集成？

持续集成指的是，频繁地（一天多次）将代码集成到主干。
举个例子。一个项目中有三个开发，分别是john、tony和susan。john在john_branch分支开发，tony在tony_branch分支开发，susan在susan_branch分支开发。他们各自的分支都可以叫支线分支，而这三个支线分支对应的功能合起来就是项目的整体功能，这三个分支合到一个分支（一般为master）上，这个分支对应的功能就是项目的整体功能，所以这个分支就叫主线分支，也叫主干。而持续集成可以理解为，在这个项目中，一天内john、tony、susan频繁地把自己的支线分支合并到主线分支上。
当然，不单纯只是合并这么简单，还包括一系列自动化的操作，这一系列的操作都是在主线分支代码发生变更（也就是有人把代码合并到主线分支上或直接在主线分支上提交）后出发的，包括自动检测、拉取、构建、代码扫描及自动化测试（单元测试、api测试、ui测试等）（后面两个步骤非必须）。
所以，持续集成可以理解为john、tony和susan在一天内频繁地把自己分支的代码提交到主干上而触发的自动检测、拉取、构建、代码扫描、自动化测试的一系列操作。

为什么要进行持续集成？

现在的软件迭代速度非常快，发布新版本的周期从过去的几个月一个版本压缩到现在的一星期一个版本甚至一两天就要发布一个新版本。在如此快速的迭代环境下，需要多个开发频繁地合并各自的分支代码到主干上，并保证新提交的变更是好的，能够适合在代码库中进一步使用，为后面的持续交付、持续部署打下基础。
简单来说就是，在迭代周期非常短的情况下，保证频繁合并到主干的代码质量是好的。

什么是jenkins？

Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具，起源于Hudson（Hudson是商用的），主要用于持续、自动的构建/测试软件项目、监控外部任务的运行（这个比较抽象，暂且写上，不做解释）。Jenkins用Java语言编写，可在Tomcat等流行的servlet容器中运行，也可独立运行。通常与版本管理工具(SCM)、构建工具结合使用。常用的版本控制工具有SVN、GIT，构建工具有Maven、Ant、Gradle。

为什么选择jenkins？

• 支持多达1000多个插件，安装即用，非常方便，凭借多样而强大的插件Jenkins成了整个开发生命周期中的一个中心点
• web的图形化界面，易学易操作
• 支持整合多个版本控制工具及构建工具

安装jenkins

安装方式有三种：

• war方式安装，需配置java环境
• exe方式安装，无需配置java环境，但需要在网页中初始化
• docker方式安装

持续集成实战

构建项目

在jenkins首页中，点击新建item：

进入构建页，可看到有很多可以构建的类型，这些都是需要安装插件才会有的，现在我们暂时用不到。我们先输入一个任务名称，然后选择：Freestyle project，点击确定：

接着进入构建的详细配置。这里我们先不设置，直接点击标签：

返回至项目的主页面，点击Build Now进行构建。由于我们没有进行设置，没有添加代码，所以现在构建的是一个空的项目。几秒钟后，显示构建成功：

接着，进入jenkins的安装目录，有一个workspace，相当于python的项目路径，这里存放的是构建的各种项目。进入workspace，可看到生成了一个跟刚刚构建项目同名的文件夹：

接下来，我们把代码放到项目目录中：

接着返回到jenkins的项目主页，进入工作空间，可看到刚刚拷贝过来的文件：

构建配置

可以看到构建配置有6个tab：

下面对每个tab进行简单说明：

general

这里是设置如何进行构建。

• 描述。项目描述,多人合作请一定要加上。
• Discard old builds。该选项配置的是如何抛弃旧的构建。
  每次构建相关的文件都会保存下来，将会渐渐耗光磁盘空间，为此提供两种方式供选择(填写数字就行，量词)：
  
  保持构建的天数：如果其值为非空的N，就留N天之内的构建文件，这是以时间为驱动的保留方式。
  保持构建的最大个数：如果#为非空，就公保留最多#个最近构建的相关文件，这是以数量为驱动的保留方式。如果有了新的构建开始，那么最早开始构建的那个任务就会删除。
• This build requires lockable resources。这个用的比较少，有一种情况可能会用到 Jekins+Appium 做自动化测试，多台手机的时候，如何让 job 可以自动选取可用设备。
• This project is parameterized。可以设置用户可输入的参数,没有输入则使用默认值,有字符串,多行字符串,布尔值等可以设置。配置的参数往往是构建允许环境中的一些环境变量。
  
  变量配置之后，往往会在构建的时候要求去输入，比如说提供一个字符串作为版本号的输入等。这些输入不仅仅单纯的是去给构建的时候增加条件，而是去脚本中传参的时候去用它。
• Throttle builds。设置两个build任务之间最小间隔和同一个时间内最大任务数量。
• 关闭构建。禁止此任务进行构建，默认是不禁止。勾选上之后，这个项目将不会有新的构建产生。一般是用于想临时保护项目（以便于不产生构建）这种情况。比如说，你的项目依赖于一些指令（测试服务器，或者源代码库），然后因为这些指令没有搭建好或者没有写好，所以会在一段时间内这个构建不可用。你可以在这个期间内勾选这个选项，这样的话可以避免你的项目去构建一些失败的任务。
• 在必要的时候并发构建。选中此选项后，可以并行执行此项目的多个版本。这个地方也一般不勾选，一般就是同一个Build触发一次构建的话下一次的构建会等上一次构建结束再进行构建这就是传说中的排队，为了安全考虑，当然如果你同时构建的话不影响可以点击这里比如你参数化那里是不同的测试发布机和发布git地址彼此完全不冲突的话这里可以勾选。将此项勾选后，可以同时执行，执行在任务自己的workspace上，默认的，使用@来区分不同的工作区，如：@2。

源码管理

这里是配置构建的源码在哪。

• 选择无，则源码所在位置就是本地，直接把源码拷贝到workspace中的项目目录下即可。
• 选择Git或Svn，则表示源码所在位置是Git或Svn上面。需要设置github或svn的url及账号的相关配置。设置完并保存后，就会拉取github或svn的代码到本地上。
  

构建触发器

这里配置的是什么条件下会触发当前项目进行构建。

• Build after other projects are built。在其他项目构建完成后再进行构建。
  
  输入的工程就是Jenkins上创建的项目名称：比如上图所示的项目名字。
  这里又分三种很通俗明了的情况，可以根据实际情况来选择：
  1.只有构建稳定时触发：其他项目构建成功后触发构建项目
  2.即使构建不稳定时也会触发：其他项目不稳定后触发构建项目
  3.即使构建失败时也会触发：其他项目构建失败后触发构建项目
  这个选项在实际工作中可以用在这样一种场景：开发在构建完业务代码的项目后，需要同时执行自动化测试。
• Build periodically。周期性进行项目构建。到达指定的时间就会自动执行构建。比如每天的9点执行。
  
  这里需要填写crontab表达式。关于crontab表达式可参考菜鸟教程：
  https://www.runoob.com/linux/linux-comm-crontab.html
• GitHub hook trigger for GITScm polling。在github上提交代码后进行构建。
• Poll SCM。定时检查源码变更（根据SCM软件的版本号），如果有更新就checkout最新的代码下来，然后执行构建动作。比如如果我想每隔30分钟检查一次源码变化，有变化就执行。

构建环境

这里是设置构建的环境。

• Delete workspace before build starts。构建开始前删除工作区。每次构建之前会把这个job所在的工作区目录里面的东西清空掉再进行构建。需要插件：Workspace Cleanup
• Use secret text(s) or file(s)。允许获取各种类型的凭据，并从shell构建步骤等中使用它们。 每个绑定都将定义一个环境变量。 需要插件：Credentials Binding
• Add timestamps to the Console Output。将时间戳添加到控制台输出
• Inspect build log for published Gradle build scans。检查已发布的Gradle构建扫描的构建日志
• with Ant：用ant

构建

这里是配置构建的执行步骤。

• Execute Windows batch command。通过执行windows的cmd指令来控制构建步骤。比如执行python run.py之后，就会去执行项目下的run.py：
  
  这里我们点击保存后，在项目主页中点击build now，在下面就会新增一个构建任务：
  
  点击任务后，再次点击控制台输出：
  
  可以看出这里输出了执行python run.py时产生的执行日志，这与直接在cmd或pycharm控制台中执行python run.py命令产生的日志是一样的：
  

构建后操作

这里设置的是在构建完成后需要进行的进一步的操作。比如说生成报告、发送邮件、构建其他项目等。

• Publish HTML reports。生成html报告。这个操作需要安装一个插件：HTML Publisher：
  
  在配置中，只需要填写两个地方即可：HTML directory to archive，指定报告的路径；Index page[s]，需要生成报告的文件名：
  
  由于HTML publisher只能生成一个报告，而一般测试报告都是有日期后缀的，所以不太实用，这里不再展开赘述。
• Editable Email Notification。配置可编辑的邮件通知。在构建完成后，就会发送给指定的邮箱。

  • 插件安装。
    需要安装一个叫email extension的插件：
    

  • 邮箱客户端-邮箱服务设置
    接着需要去邮箱客户端中开启邮件服务。这里以QQ邮箱为例。
    进入设置：
    
    开启POP3/SMTP服务：
    
    经过一系列设置后，获得邮件服务授权码：
    

  • Jenkins-邮件服务器配置
    接着进入jenkins- Manage Jenkins-Configure System：
    系统管理员邮件地址中输入管理员的邮箱地址：
    
    SMTP server输入邮件服务器的url：
    
    在Extended E-mail Notification中，smtp server输入邮件服务器url，接着在下面输入发件人邮箱地址及邮箱服务授权码：
    
    Default Recipients配置的是默认收件人邮箱地址：
    
    勾选以下两个选项：第一个是允许在控制台中打印出错误信息，方便调试；第四个是允许发送给未注册的用户：
    

  • 操作设置
    

Project Recipient List：收件人邮箱地址列表。可填写，也可使用环境变量：$DEFAULT_RECIPIENTS读取系统设置中默认收件人列表。
Content Type：内容类型。
Project Reply-To List：回复人列表。
Default Subject：邮件标题。
Default Content：邮件内容。
Attachments：附件路径。相对于当前项目的路径。
Triggers：什么条件下会触发发送邮件的动作。这里有很多条件可以选：总是（无论是否成功都发送邮件）、成功、失败、构建前等。

保存后进行构建，可在控制台中看到发送邮件时的相关日志：

构建成功后，可收到邮件：

分布式构建

为什么要进行分布式构建？

当前服务器进行自动化测试时比较耗资源，可使用多台从服务器进行分布式构建

如何进行分布式构建？

可参考以下文章：
https://blog.csdn.net/xiangff_csdn/article/details/76954708