jenkins

来源:互联网 发布:java教程博客 编辑:程序博客网 时间:2024/03/29 03:23

持续集成

在介绍jenkins之前需要先了解一个概念CI(Continuous Integration)持续集成,不了解的可以先看下这篇文章:持续集成,这个概念来自很流行的敏捷开发,讲究快速的发现问题,快速发现问题需要的是快速的迭代开发,不同于传统的瀑布式开发。持续集成解决了软件开发过程中的很多痛点。最好的代码提交方式是:在本地经过一系列测试后,再提交到版本控制系统。而且提交要尽可能的小批量频繁提交,因为这有助于迅速发现和解决问题。

jenkins简介

了解了CI的概念,那么jenkins是什么,其实就是我们实现CI的一种工具,jenkins是开源的,当然业界还有其他的CI工具,但是jenkins使用的是最广泛的,它的前身是Hudson。jenkins的实现架构和eclipse非常相似(基于插件),想想eclipse的强大功能,jenkins同样可以通过扩展的插件来实现丰富的功能。jenkins提供了非常简洁的页面来管理这些插件和构建任务。jenkins默认对于CVS和SVN提供了方便的支持,对于项目管理工具则能够很好的支持Maven,如果你的项目是基于maven来管理的,那么使用jenkins会感觉到异常的简单。

同时jenkins非常善于站在一段时间的角度上,分析构建的稳定性,不同的稳定性使用不同的天气标示。比如阴天,晴天,等,都表示不同的含义。

jenkins的安装

Jenkins很容易安装,可以跑在任何地方。你可以把它作为单独的应用程序或者运行在Java应用服务器比如Tomacat中。因为Jenkins是一个java应用程序,你需要在机器上安装jdk。Jenkins有一种war包形式的安装包,可以下载最新的版本。

jenkins中的job

一个完整的构建可能需要很多步骤,每个步骤都称作是一个job。一个build job是一个专一做某事的步骤,比如编译,测试,打包,部署等等。构建任务是各种各样的。可能你需要去编译源码,对程序做单元测试,生成代码的质量报告,生成api文档,部署应用,做自动化测试等等。

jenkins中提供了自由式的风格,maven风格等几种job模式。

最简单的jenkins应用

目前绝大多数的开发团队都会使用版本控制系统来管理源代码,因此一种最简单的使用jenkins的场景诞生了。我们知道软件开发中最基本的一个步骤就是编译源码,现在的很多IDE都支持该功能。但是如何去编译版本控制系统的代码,最简单和常用的方式是自己写一个编译脚本,比如ant脚本。如果你们的项目使用的maven,那当然更简单,其他的诸如git等就不在讨论了。jenkins最基本的一个功能就是:当有人提交代码到版本控制系统的时候,就拿SVN来说吧,jenkins能够自动检测到代码的变化,并将源代码下载到jenkins服务器本地,然后调用构建脚本去编译源码。这是最基本的一个场景。后面复杂的jenkins流水线都是基于此。

除了提交构建,也能够定义隔某段时间便构建一次,或者定时轮询SCM的改变去触发构建。当然也支持手动的构建,这些都统称为构建触发器。构建步骤中可以执行我们自定义的shell或者batch等等脚本,非常的灵活。

Jenkins的家目录

上面提到jenkins服务器本地,其实jenkins为每个项目都会建立一个自己的workspace,源码会下载到这个目录下,然后编译的动作在该目录中进行。这里不得不提到jenkins中一个非常重要的概念——JENKINS_HOME  jenkins的家目录,可以为该环境变量指定一个值否则会使用默认值。该目录的结构大概为:


jobs下面按照项目的维度进行划分,每个项目下有builds和workspace目录,其中我们所讲的源码会保存在各个项目的workspace中,builds目录包含构建的历史记录。

自动化测试

如果jenkins仅仅能够做编译源码的动作,那你太小看他了,源码编译出来的可执行文件比如war包jar包等等,jenkins统统能够帮你管理起来。jenkins同样有很多插件方便完成自动化的测试,这些测试包括单元测试,功能测试,集成测试,性能测试,验收测试等等,其中开发的过程可以使用TDD等方式来进行。进行自动化的测试仅仅是一部分功能,其中比较重要的是需要收集测试的结果,如果能够以图形化的方式展示出来那就更好了。没错,jenkins能够做这些事情,只需要告诉jenkins测试的结果在哪里,它会去取,并且生成可视化的图形。

另外一种关于自动化测试的是代码的覆盖率,jenkins同样支持对代码覆盖率的统计。

通知

一旦编译失败或者测试失败或者代码质量不合格等等,需要立马让相关的人知道情况,通常的方式是发送email,只需要在jenkins上简单的配置SMTP服务器等一些步骤即可,当然通知不仅仅这么简单,还有些复杂的功能,比如更具不同的人发送不同的邮件内容。或者直接使用即时通讯软件发送即时消息。或者发送短信。这些jenkins都能实现。

代码质量

在各种自动化测试都完毕的时候,一般需要进行代码的质量度量,比如圈复杂度,checkstyle,findbugs等等静态检查。这些检查都可以使用jenkins的插件完成,同样会收集质量结果,做展示,很方便开发人员进行代码重构。

自动化部署

自动化部署目的就是减少不必要的时间。最简单的是自己实现部署的脚本然后供jenkins去调用,但是对于复杂的部署需求,自己实现脚本恐怕有些力不从心,我们可以借助插件完成——Puppet或者Chef。

关于数据库的自动化升级可以使用脚本实现或者使用工具Liquibase。

自动化升级中需要关注的是回滚的问题,解决回滚的最简单的思路是升级前的备份。包括应用和数据库的数据。

高级构建

参数构建类似普通的构建任务,但是功能更强大。可以为本次构建指定一些参数,这些参数可能会在某几个构建中被使用到,参数的传递由jenkins去维护。由此一个普通的构建通过获取不同的参数能够表现的更多样化。

更强大的是多配置构建,类似参数构建,提供一个配置列表,比如针对不同的数据库或者浏览器的列表,jenkins会自动的执行不同场景下的测试,这些测试可以并行的执行,从而大大的减少了测试的时间。

分布式构建

jenkins也支持master/slave的分布式方式,master主要用来分发构建任务给slave,实际的执行在slave中。Master监控slave的状态,并收集展示构建的结果。但是在实际情况中master同样可以执行构建任务。可以通过master指定某个项目总是运行在特定的slave或者某类slave或者简单的任何一台slave中。

分布式构建中,jenkins提供了对代理节点的监控,如果发现某台slave不可用,则会主动将其下线,避免后续的任务被分配到该节点上。

流水线

所谓的流水线很容易理解,就是整个构建流程按照一定的流程去构建。当你的构建步骤变得复杂的时候,并且并行和串行都有的时候,通常就不太容易管理了。流水线能够方便的定义某个构建后要触发的下一个构建,或者同时触发的后面几个构建。当然也能够等待某几个构建执行完毕后去执行某一个构建。其中TheDependency Graph View插件能够帮助你分析构建任务之间的关系。并且如果涉及到构建的资源竞争,也提供了锁的功能。

jenkins中的安全管理

jenkins中有个维度来管理安全,一个是安全域一个是授权。安全域能够识别出合法的用户,授权针对合法的用户给出不同的权限。最简单的授权是允许所有的合法用户做任何事情。

最简单的管理用户账号的方式是使用jenkins内建的数据库,但是也能够和其他的用户管理系统做集成。针对授权有好多种不同的策略,比如基于项目,基于角色。

另外一种重要的功能是审计,也就是记录用户的操作日志。有两种插件能够实现该功能。Audit Trail插件能够记录用户的操作动作。JobConfigHistory插件能够存储前一个版本系统的变化和job的配置文件。

总结:

持续集成一般会经历一下几个阶段

阶段一—没有构建服务器

最初的阶段,团队没有任何一种构建服务器。软件由开发人员手动的去构建,尽管使用的是Ant脚本或者类似的东西。源码可能存储在一个中央源码仓库中,但是开发者未必要定期的提交更改后的代码。有时候在一个版本要发布的时候,开发人员手动的去集成这些变化,这是一个非常痛苦的过程。

阶段二—夜间的构建

在这个阶段,团队有一台构建服务器,并且定时的去执行构建任务(通常在夜里)。因为并没有一个可靠的可重复的单元测试,所以这里的构建通常只是代码编译。如果有自动化测试,也并没有强制集成到构建阶段,也许根本不会正确的运行。但是现在开发人员已经能够有规律的定期提交代码了,至少在每天下班前。如果一个开发人员提交的代码和另外一个人有冲突,构建服务器会在第二天的早上将告警通过邮件发出来。然而,整个团队只是将构建服务器作为一个参考—如果构建挂了,他们并没有意识去立即把它修复好,因此构建可能会在一段时间内不可用。

阶段三—夜间构建和基本的自动化测试

团队现在已经更加严格的使用持续集成和自动化测试了。构建服务器被配置为当有代码提交的时候便会执行构建,团队的成员也可以很方便的看到是哪些代码中的变化引起了构建,这些变化引发了什么问题。除此之外,构建脚本编译应用并且自动的执行一些单元和集成测试。对于邮件,构建服务器能够更加积极主动的去呈现构建中出现的问题。失败的构建也能够被快速的修复。

阶段四—进入度量

自动化的代码质量和覆盖率度量也能够执行了,并且可以帮助评估代码的质量和测试的相关性和有效性。代码质量的构建也能够为应用生成API文档。所有的这些帮助团队去维护高质量的代码。团队中可以设置一个醒目的屏幕去时刻展现项目的状态。

阶段五—更严格的测试

持续集成的好处是非常接近立体的测试。现在,测试驱动开发(TDD)被广泛的应用,对于自动构建的结果更加的有信心。对于应用程序不再是简单的编译和测试,而是会继续更复杂的端到端测试和性能测试。

阶段六—自动化验收测试和自动化部署

验收测试驱动开发(Acceptance-Test Driven Development)在这个阶段被应用,引导开发的工作并且提针对项目的状态提供一个高层次的报告。这些自动化测试使用行为驱动测试(Behavior-Driven Development)和验收测试驱动开发工具,并且从商业的角度生成开发人员不理解的报告。因为这些高层次的测试在项目的早期开展,因此能够清晰的指出,哪些特性已经完成了,哪些需要后面去完成。每当代码有改变或者夜里,应用程序被自动的部署到QA的测试环境来完成测试。当测试人员完成了充分的测试后,应用程序可以被一键式的部署到生产环境。当然也能够通过构建工具去备份当前的发布版本,或者当有问题出现的时候,回归当前的版本。

阶段七—持续部署

处于对自动化的单元、集成、验收测试的信任,现在团队能够应用自动化部署技术,直接将新的特性增加到前一个版本中,该版本处在生产环境中。

这些阶段可以是按部就班的来,但有时候也不一定非得按照上面的步骤,比如在集成代码质量和覆盖率测试之前可以先完成自动化的web测试。这里只是给出了部署一套CI的常规流程。


0 0