Jenkins 就是常说的 CI 平台（持续集成）。持续集成(CI)是一种实践，可让团队在持续的基础上收到反馈并进行改进，没必要等到开发周期后期才寻找和修复缺陷。java

改进确定是本身改进，反馈是谁提供呢？python

最早应用在开发团队中，也就是“打包”。大型项目都是 Java 写的，它会遇到一些依赖包缺乏了，语法写错了，引用的依赖文件没有或者依赖文件的函数被其它开发改了。git

这个状况下去打包，就必定会打包失败而且完整告诉你哪一个文件哪行代码出了什么错。开发人员在收到错误反馈后就会修改代码而后从新打包。这个就是尽早得发现它的问题，因此就是 Jenkins 发邮件的形式来反馈的。web

没有 Jenkins 平台的时候有这些问题遇到：

Bug 老是在最后才发现（必定要提交到测试才会发现比较严重的 bug，在开发阶段可能发现不了）
越到项目后期，问题越难解决
软件交付时机没法保障
程序常常须要变动（前期不怎么改问题，到后面要上线了没办法，加班加点改，改完测试就得测）
无效的等待变多

长期得开发过程当中无人监控，只构建打包没法保证产品质量。Jenkins 的定时任务在固定的周期内检测代码Jenkins 作全方位的质量监控。shell

版本管理提交代码，同时也要下载到本地更新一下。这个过程当中开发是有不少个的：安全

可能出现 2 我的都要更改这个文件。或者我更改 A 和 B，可是个人 A 当中是有引用 B 的。我天天都要提交代码。既然有这么多人向版本管理系统提交代码，我须要检测下他们的代码可否能正常打包成一个文件，有没有引用的错误，语法的错误，有没有缺依赖包等等，这个都是经过将文件编译打包。服务器

编译是将它打包成.class文件，这个文件更好得让机器执行。编译成.class文件得时候，假如文件 A 里面引入了文件 B，那么在编译得时候全部依赖得第三方库以及外部文件必须都能访问获得而且正确才能编译成功。微信

打包很简单，重要得是编译过程。打包包含了编译。天天都去编译打包，天天都能发现问题。框架

1.开发阶段

静态代码检测是个什么意思？

经过 Jenkins 平台来自动对代码进行静态检查。sonarQube 能够作这些事，它能够帮你发现基本的语法规范出错了和安全隐患问题。运维

1.什么是静态代码？

就是你的源码，就是在 svn 上面下载下来的源码库。去解析处理，若是这些都经过了就上线，没经过就修改你的代码。

sonarQube 能够和 Jenkins 完美得集成。sonarQube 会扫描出来究竟是谁写的代码。哪个文件，哪一行存在安全隐患。是什么安全隐患，应该如何修改以及哪一行代码有这个语法规范问题。请及时修改。

2.什么语法规范？

重复度。 作一个大型的系统讲究分层设计，下降它的重复度，提升它的灵活度。若是给一个项目的代码给我，我扫描出来达到 50%的重复度。重复度过高就意味着很是得不灵活，通用共享作的太少。sonarQube 会给出提示，很明白告诉你，哪些文件的多少行是重复的。

就须要召集开发团队赶忙把问题改改，将重复度降下来。

复杂度。 若是一个函数或者一个类里面的复杂度过高（for 循环，if else，for 循环不宜作的太深，2 层就够了。3-4 层，再下去复杂度就过高）。复杂度越高就意味着这个函数太难懂了，问题的可能性也很是大。

若是复杂度偏高，那你就要想办法将这个偏高的函数想办法将它简单化，下降它的复杂度，这样它的流程以及 bug 方面就不会有那么多。sonarQube 会从全方位的角度帮你检测你的整个项目在代码层面有哪些问题须要你去改。

sonarQube 会集成单元测试、自动化测试。还能够检测自动化代码的覆盖率。它不分语言，python、java 等都是能够作的。每一种语言都有对应的规则库，你都是能够下载的。自动化代码也是代码，你拿它去扫一扫，同样会给你个结果。

在正式编译打包以前，把静态代码检查先作了。若是尽早介入，不是等代码所有开发完成才介入。

定时来作这 2 件事：

能够从开发层面很好地把控代码质量。既然加入了 Jenkins，就会有邮件通知也会有报告展现。开发人员能够每周作一次总结并处理。

能够经过 Jenkins 再作单元测试，这个须要开发人员本身配合了，他们本身写了单元测试代码，咱们才能将单元测试代码集成到 Jenkins 平台。若是开发不写，咱们怎么测呢？

先作完静态检查，将它编译打包后，对打包后的代码进行单元测试，这个从总体的代码层面不是从业务层面，而是你代码的优质程度。单元测试从本身写的业务函数层面、系统功能层面，来自我检测一下这个有没有问题。

开发代码迭代： 每个星期给测试转一个测试版本，这个版本应该作单元测试。那么下一个星期，在历史的长河中，在软件开发的 2 年当中，逐步加内容改内容的时候必定会影响历史模块。

若是在这个过程当中，你开发的每个模块都带了单元测试，每次你转到测试以前所有都作次单元测试。若是你改了加了新的代码，影响了旧的代码可是你没有改，单元测试立刻就会暴露出来。

开发人员在自个人层面来控制代码的质量，这就不用等到测试告诉你这个功能明明是好的，为何到了这个版本又挂了？你在单元测试阶段就会发现。

可是，国内的场景是没有多少开发有作单元测试的意识。即便有的开发有这个想法，时间上也不容许。开发任务过重了，致使功能层面的代码质量所有压在了测试的身上。可是测试工程师不是万能的，不少隐藏的问题，尤为是开发层面的大 bug，咱们通常是看不到的，除非是有些状况把它触发出来了。

因此这 3 个角度，是从开发人员业务和代码质量水平两个维度来把控代码质量。若是开发人员能把这 3 件事作好，到了测试的手上，问题基本上已经解决了一大半，很流畅，即使你要新增什么模块，优化什么的，在单元测试这个地方就直接暴露出来了。

2.测试阶段

1.环境部署

首先，环境部署，多是测试作，可能不是测试作。环境有不少套：好比 DEV（开发环境）、SIT 环境(系统集成测试)、预发布环境。

DEV 环境有 1 套，SIT 环境有 4 套，预发布环境 1 套，一共 6 套环境。会有专门的环境管理人员，可是人家重点是服务器方面的维护。可经过 Jenkins 平台作自动部署。 发布、部署测试版本的时候不须要去找环境管理人员了，直接在 Jenkins 平台上点击触发下这个工程构建就 Ok 了。

自动部署就是打包以后将这个包（这个包和 DEV 环境是同步的），将它部署到测试环境当中，而后解包出来。

测试包部署流程： 开发通常只部署本身的测试环境，测完包后给到测试。正式环境通常都是运维。通常部署可能部署到 Linux 服务器上，而咱们编译打包是直接能够在 Windows 机制上执行，固然也能够在 Linux 机制上执行。

要下载最新的代码将它打包，打包以后传送到测试服务器上。在测试服务器上再去将这个包解压到对应的路径下面（前提是经过网址访问将测试环境的服务停掉）。把这个包部署上去，更新代码以后，再将这个环境启动起来，完毕之后才能作测试。

若是想作这个事，先找开发好好了解下部署流程怎么作的，就知道怎么部署啦。部署完成以后就能够作自动化测试了。部署过程当中会涉及各类操做，会涉及 python 脚本、shell 脚本，还用到上传的软件（vpm\ftp），全看本身公司内部是怎么作的了。知道流程以后，再想一想每一步我用代码如何实现。而后将这个代码归入到 Jenkins 步骤当中，一步一步去作。