Jenkins集成robotframework

持续集成理念

持续集成（CI)是一种实践，可以让团队在持续基础上收到反馈并进行改进，不必等到开发周期后才寻找和修复缺陷。

它的好处有几个方面：

● 快速发现错误：每完成一点更新，就集成到主干代码，可以快速发现错误，定位错误也比较容易。

● 防止分支大幅偏离主干：如果不是经常集成，主干代码又在不断更新，会导致以后集成的难度变大，甚至难以集成。

● 减少重复性的工作：通过自动化的持续集成可以将编译、部署、测试等动作都变成自动化的，无需太多人工干预。

部署job流水线，使得一个应用程序从构建、部署、测试和发布这个过程实现自动化，是现代DevOps理念的核心组成部分。在不同的企业内部，部署流水线的具体实现是不一样的，但基本原理都是相同的。

一般常见流水线：提交代码->静态代码扫描->单元测试->编译打包->自动部署->接口自动化测试->UI自动化测试->发布生产环境->用户验证阶段

• 部署方式：

      1、触发式构建：用于开发环境部署，开发人员push代码或者合并代码到svn项目的master分支，jenkins就部署代码到对应服务器。

      2、参数化构建：用于测试环境预上线环境部署，开发push代码或者合并代码到svn项目的master分支之后，并不会部署代码，而是需要登录到jenkins的web界面，点击构建按钮，传入对应的参数（比如参数需要构建的tag，需要部署的分支）然后才会部署。

      3、定时构建：用于自动打包，定时构建是在参数化构建的基础上添加的，开发人员可以登录jenkins手动传入tag进行打包，如果不手动打包，那么jenkins就每天凌晨从SVN拉取最新的代码打包。

持续集成基本配置

本环境整体思路部署技术方案：SVN + RF + Jenkins + nginx + cenos7 + Allure

• 新建节点

1. 系统管理—>节点管理—>新建节点 
2. 虚拟机cetnos系统部署是Jenkins平台，采用master主节点管理各子节点，因项目是基于windows环境执行用例，需要在添加子节点windows环境，当然也可添加基于linux环境子节点，视项目运行环境而定。
3. 添加子节点可以是物理机也可以是虚拟机。
4. 标签作用根据各子节点对应的标签主机哪台空闲就自动调用哪台主机构建执行

 

新建子节点，平台会有提示下载slave-agent.jnlp到子节点机子，不能可以通过在子节点命令行启动子节点。如下图所示：

这里通过打开JAVA控制面板运行脚本启动，子节点slave-windows会变成在线状态。如下图所示：

• 新建job

这里选择自由风格软件项目，然后设置job任务名称。

• 配置General

这里选择丢弃旧的构建，保持构建建天数3天，最大个数3，设置限制运行节点标签为robot，其它更多参数视实际项目及环境而定。

• 源码管理

1. 设置SVN版本库路径及账户密码
2. 其它默认，也可根据实际情况配置其它参数

• 触发构建器

● 定时构建表示设定的时间点进行自动触发构建

● 轮询SCM表示检测提交代码到SVN并自动触发构建，这里设定每隔5分钟检测SVN状态，只要状态有变化在5分钟后进行触发构建

● 检测SVN状态，需要在主节点Jenkins服务器的SVN版本库修改钩子脚本

● 定时任务触发时间表达式

采用了著名的UNIX任务调度工具CRON所使用的配置方式。用5个字段代表5个不同的时间单位（中间用空格隔开）：

分 时 日 月 星期几

举例：

0 2 * * *    表示每天凌晨2点

*/10 * * * *   每隔10分钟一次

45 10 * * 1-5    每周星期一到星期五的10：45分执行

• 构建

● 演示环境目前未涉及到构建环境，视实际项目和环境而定。

● 项目是基于windows执行自动化用例，这里选择windows批处理命令，也就是构建时候自动下发命令执行自动化用例

● 如项目是基于linux环境运行，需要选择执行shell选项并设置参数

• 构建后操作

● Path采用相对路径，目录名必须与构建批处理一样目录名

● Robot output设定项目执行后存放的报告路径

● bulid result是指设定阀值

注意：构建后操作输出的结果必须与前图构建的批处理脚本路径要求一致性。

• 邮件配置

● 这里设置邮件相关参数，可以在此job配置数据，如不设置数据，需使用默认变量的，要在系统管理—>系统配置里面配置好

● 邮件内容样式可以自定义模板，需要使用前端技术编写好

● Attach Build Log：表示接收到邮件含有构建log日志文件

● Attachments：表示接收到邮件含有报告附件文件

这里采用默认方式。

• 邮件Triggers

● triggers有很多种，我们使用最多的就是success和failure，always表示每次构建都发送邮件

●可以给每个策略选择不同的收件人：
    1、Recipient List :在策略中配置的收件人列表
    2、Developers:发送给检测到的代码修改的开发人员
    3、Requestor:发送给触发这次构建的用户
    4、Clprits:发给引发错误的开发人员

• 系统管理的邮件全局配置

注意：邮箱的密码必须是授权码，不是邮箱的登录密码。

• 设置邮件的Triggers

• 平台展示

• robotframework报告展示样本

• Allure报告展示样本

• 构建后自动发出的邮件接收到的报告样本展示一

• 构建后自动发出邮件接收到的报告样本展示二

备注：因每个用例执行速度达到毫秒级，所以表格显示的是0分0秒。