Maven · 使用 Hudson 进行持续集成
- [1️⃣ 持续集成的作用、过程和优势](#1️⃣ 持续集成的作用、过程和优势)
- [2️⃣ Hudson 简介与安装](#2️⃣ Hudson 简介与安装)
- [3️⃣ 准备 Subversion 仓库](#3️⃣ 准备 Subversion 仓库)
- [4️⃣ Hudson 的基本系统设置](#4️⃣ Hudson 的基本系统设置)
- [5️⃣ 创建 Hudson 任务](#5️⃣ 创建 Hudson 任务)
-
-
- [5.1 Hudson 任务的基本配置](#5.1 Hudson 任务的基本配置)
- [5.2 Hudson 任务的源码仓库配置](#5.2 Hudson 任务的源码仓库配置)
- [5.3 Hudson 任务的构建触发配置](#5.3 Hudson 任务的构建触发配置)
- [5.4 Hudson 任务的构建配置](#5.4 Hudson 任务的构建配置)
-
- [6️⃣ 监视 Hudson 任务状态](#6️⃣ 监视 Hudson 任务状态)
-
-
- [6.1 全局任务状态](#6.1 全局任务状态)
- [6.2 自定义任务视图](#6.2 自定义任务视图)
- [6.3 单个任务状态](#6.3 单个任务状态)
- [6.4 Maven 项目测试报告](#6.4 Maven 项目测试报告)
-
- [7️⃣ Hudson 用户管理](#7️⃣ Hudson 用户管理)
- [8️⃣ 邮件反馈](#8️⃣ 邮件反馈)
- [9️⃣ Hudson 工作目录](#9️⃣ Hudson 工作目录)
- [🌾 总结](#🌾 总结)
作为最核心的敏捷实践之一------持续集成 (Continuous Integration
) 越来越受到广大开发人员的喜爱和推崇。借助前文讲述的Maven 所实现的自动化构建正是持续集成的一个必要前提,持续集成还要求开发人员使用版本控制工具和持续集成服务器。例如 Subversion(SVN)
、GIT
就是当前最流行的版本控制工具,而 Hudson
则是一个开源持续集成服务器软件。本文将简要介绍持续集成的概念和 Subversion
的基本使用,主要关注如何使用 Hudson
, 尤其是如何结合 Maven 与 Hudson 持续集成我们的项目。
1️⃣ 持续集成的作用、过程和优势
简单地说,持续集成就是快速且高频率地自动构建项目的所有源码,并为项目成员提供丰富的反馈信息。这句话有很多关键的词:
- 快速: 集成的速度要尽可能地快,开发人员不希望自己的代码提交半天之后才得到反馈。
- 高频率: 频率越高越好,例如每隔一小时就是个不错的选择,这样问题才能尽早地 被反映出来。
- 自动: 持续集成应该是自动触发并执行的,不应该有手工参与。
- 构建 :包括编译、测试、审查、打包、部署等工作。
- 所有源码: 所有团队成员提交到代码库里的最新的源代码。
- 反馈: 持续集成应该通过各种快捷的方式告诉团队成员最新的集成状态,当集成失 败的时候,反馈报告应该尽可能地反映失败的具体细节。
一个典型的持续集成场景是这样的:开发人员对代码做了一些修改,在本地运行构建并确认无误之后,将更改提交到代码库。具有高配置硬件的持续集成服务器每隔30分钟查 询代码库一次,发现更新之后,签出所有最新的源代码,然后调用自动化构建工具(如 Maven) 构建项目,该过程包括编译、测试、审查、打包和部署等。然而不幸的是,另外一名开发人员在这一时间段也提交了代码更改,两处更改导致了某些测试的失败,持续集成服务器基于这些失败的测试创建一个报告,并自动发送给相关开发人员。开发人员收到报告后,立即着手调查原因,并尽快修复。
下图形象地展示了整个持续集成的过程:
通过图中所示,当持续集成服务器构建项目成功后,还可以自动将项目构件部署到 Nexus 私服中。
一次完整的集成往往会包括以下6个步骤:
- 持续编译: 所有正式的源代码都应该提交到源码控制系统中(如
Subversion
), 持续 集成服务器按一定频率检查源码控制系统,如果有新的代码,就触发一次集成,旧的已编译的字节码应当全部清除,然后服务器编译所有最新的源码。 - 持续数据库集成:在很多项目中,源代码不仅仅指 Java 代码,还包括了数据库 SQL 脚本,如果单独管理它们,很容易造成与项目其他代码的不一致,并造成混乱。持续集成也应该包括数据库的集成,每次发现新的 SQL 脚本,就应该清理集成环境的数据库,重新创建表结构,并填入预备的数据。这样就能随时发现脚本的错误,此外,基于这些脚本的测试还能进 一 步发现其他相关的问题。
- 持续测试:有了JUnit 之类的框架,自动化测试就成了可能。编写优良的单元测试并不容易,好的单元测试必须是自动化的、可重复执行的、不依赖于环境的,并且能够自我检查的。除了单元测试,有些项目还会包含一些依赖外部环境的集成测试。所有这些测 试都应该在每次集成的时候运行,并且在发生问题的时候能产生具体报告。
- 持续审查:诸如
Checkstyle
和PMD
之类的工具能够帮我们发现代码中的坏味道(Bad Smell), 持续集成可以使用这些工具来生成各类报告,如测试覆盖率报告、Checkstyle报告、PMD报告等。这些报告的生成频率可以低一些,如每日生成一次,当审查发现问题的时候,可以给开发人员反馈警告信息。 - 持续部署:有些错误只有在部署后才能被发现,它们往往是具体容器或者环境相关的,自动化部署能够帮助我们尽快发现这类问题。
- 持续反馈:持续集成的最后一步的反馈,通常是一封电子邮件。在重要的时候将正确的信息发送给正确的人。如果开发者一直受到与自己无关的持续集成报告,他慢慢地就 会忽略这些报告。基本的规则是:将集成失败报告发送给这次集成相关的代码提交者,项目经理应该收到所有失败报告。
持续集成需要引入额外的硬件设置,特别是对于持续集成服务器来说,性能越高,集成的速度就越快,反馈的速度也就越快。持续集成还要求开发者使用各种工具,如源码控 制工具、自动化构建工具、自动化测试工具、持续集成软件等。这一切无疑都增加了开发人员的负担,然而学习并适应这些工具及流程是完全值得的,因为持续集成有着很多好处:
- 尽早暴露问题: 越早地暴露问题,修复问题代码的成本就越低。持续集成高频率地
编译、测试、审查、部署项目代码,能够快速地发现问题并及时反馈。 - 减少重复操作:持续集成是完全自动化的,这就避免了大量重复的手工劳动,开发
人员不再需要手动地去出源码, 一步步地编译、测试、审查、部署。 - 简化项目发布: 每日高频率的集成保证了项目随时都是可以部署运行的,如果没有
持续集成,项目发布之前将不得不手动地集成,然后花大量精力修复集成问题。 - 建立团队信心:一个优良的持续集成环境能让团队随时对项目的状态保持信心,因
为项目的大部分问题区域已经由持续集成环境覆盖了。
既然持续集成有那么多优点,现在让我们开始动手架设自己的持续集成环境吧!
2️⃣ Hudson 简介与安装
优秀的持续集成工具有很多,如老牌的开源工具CruiseControl 、商业的 Bamboo 和 TeamCity 等。这里只介绍 Hudson, 因为它是目前较流行的开源持续集成工具。该项目过去一直托管在 java.net 社区,不过现在已经迁移到 http://hudson-ci.org/
。Hudson 主要是由Kohsuke Kawaguchi 开发和维护的,Kohsuke Kawaguchi 自2001年就已经加入 Sun 公司(当然,现在已经是 Oracle 了)。
Hudson以其强大的功能和易用的界面征服了大量的用户,它与主流的构建工具、版本控制系统以及自动化测试框架都能进行很好的集成。因此,很多组织和公司选择它作为自 己的持续集成工具,如JBoss 的 http://hudson.jboss.org/hudson/
和 Sonatype 的 https://grid.sonatype.org/ci/
。
Hudson 还有一个优秀之处就是它提供了灵活的插件扩展框架,大量开发者基于这种机 制对Hudson 进行了扩展。
安装 Hudson 是十分简便的。需要注意的是, Hudson 必须运行在JRE1.5 或更高的版本 上。可以从 http://hudson-ci.org/
下载最新版本的安装包。下载完成之后就能获得一个 hudson.war
文件。
最简单的启动 Hudson 的方式是在命令行直接运行 hudson.war:
bash
$java -jar hudson.war
Hudson 的启动日志会直接输出到命令行,待启动完成之后,用户就可以打开浏览器输 入地址 http://localhost:8080/
访问 Hudson 的界面了。要停止 Hudson, 可以在命令行按下 Ctrl+C 键 。
默认情况下 Hudson 会在端口8080下运行,这可能会与用户已有的Web 应用相冲突。 这时,用户可以使用 --httpPort 选项指定 Hudson 的运行端口。例如:
bash
$java -jar hudson.war --httpPort=8082
既然安装包是一个 war 文件 ,Hudson自然也就可以被部署到各种 Web 容器中,如 Tomcat 、Glassfish 、Jetty 及 JBoss 等 。
这里以Tomcat 6 为例,假设Tomcat 的安装目录为 D:\bin\apache-tomcat-6.0.20\
, 只需要复制 hudson.war 至 Tomcat 的部署目录 D:\bin\apache-tomcat-6.0.20\webapps
, 那么然后转到 D:\bin\apache-tomcat-6.0.20\bin\
目录,运行 startup.bat 。 这时可以从Tomcat 的 console输出中看到它部署 hudson.war。
待 Tomcat 启动完成之后,打开浏览器访问 http://localhost:8080/hudson
就能看到 Hudson 的界面了。用户可以将Tomcat 作为一个系统服务运行,这样 Hudson 就能自动随操作系统一起启动了。
3️⃣ 准备 Subversion 仓库
在正式创建 Hudson 持续集成任务之前,需要准备好版本控制系统。常见的版本控制工 具有 CVS 、Subversion 、Git 、Mereurial 等。由于 Subversion 可能是当前使用范围最广的版本控制工具,因此以它为例进行介绍。
首先需要安装 Subversion 服务器软件(仅讨论 svnserve) 。 对于大多数 Limux 发行版和 MacOSX来说,该工具应该已经被预先安装了。可以运行如下的命令查看,见代码:
bash
$svnserve --version
svnserve,version 1.5.5(r34862)
compiled Dec 23 2008,16:20:31
Copyright(C)2000-2008 CollabNet,
Subversion is open source software,see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net /).
The following repository back-end(FS)modules are available:
*fs_base:Module for working with a Berkeley DB repository.
*fs_fs:Module for working with a plain file (FSFS)repository.
Cyrus SASL authentication is available.
对于Windows用户来说,可以安装 Slik Subversion(http://www.sliksvn.com/en/download
)。需要注意的是,在选择安装类型的时候,需要选择complete安装,否则默认的安装方式将不会安装svnserve。
安装完成之后,可以运行如下命令进行验证,见代码:
bash
D:\>svnserve --version
svnserve, 版本1.6.2(SlikSvn:tag/1.6,2 @37679)WIN32
编译于 May 11 2023,13:06:15
版权所有(C)2000-2009 CollabNet.
Subversion 是开放源代码软件,请参阅 http://subversion.tigris.org/站点.
此产品包含由 CollabNet (http://www.Collab.Net/)开发的软件。
下列版本库后端(FS) 模块可用:
*fs_base: 模块只能操作 BDB 版本库.
*fs_fs: 模块与文本文件(FSFS) 版本库一起工作.
Cyrus SASL 认证可用.
接着需要创建一个 Subversion 仓库。运行命令如下:
bash
D:\>mkdir svn-repos
D:\>svnadmin create svn-repos\account
svnadmin 是用来创建、维护、监测 Subversion 仓库的工具,在主流Linux和 Mac OS X上一般都是预装的。在 Windows上,它也被包含在 Slik Subversion 中。这里首先创建一个名为 svn-repos的目录,然后在这个目录中创建一个 Subversion 仓库。
下一步是将之前背景案例现有的代码导入到这个 Subversion 仓库中。由于笔者的代码和 Subversion 仓库在一台机器上,因此直接使用file协议导入(导入之前应先使用mvn clean 命令清除项目输出文件,这些文件是可以自动生成的,不该放入源码库中), 见代码:
bash
$svn import -m "Initial import". file:///D:/svn-repos/account/trunk
增加 account-email
增加 account-email\src
增加 account-email\src\test
增加 account-email\src\test\java
增加 account-email\src\test\java\com
增加 account-email\src\test\java\com\xiaoshan
增加 account-email\src\test\java\com\xiaoshan\mvnbook
增加 account-email\src\test\java\com\xiaoshan\mvnbook\account
增加 account-email\src\test\java\com\xiaoshan\mvnbook\account\email
...
...
增加 account-captcha \pom.xml
提交后的版本为1.
上述命令将当前目录的全部内容提交到 Subversion 仓库的 /account/trunk 路径下, -m 选项表示提交的注释。
仓库建立并初始化完毕,就可以启动 svnserve 服务了:
bash
$svnserve -d -r svn-repos --listen-host 0.0.0.0
选项 -d 表示将svnserve 服务作为守护进程运行, -r 表示Subversion 仓库的位置,而参 数 --listen-host是为了强制将svnserve绑定到 IPv4 地址(在有些系统上,svnserve 会默认 绑定IPv6 地址,当Hudson 使用 IPv4 地址访问Subversion 仓库的时候就会失败)。
最后,可以用简单的 svn命令检查插件 svnserve服务是否可用,见代码:
bash
$svn list svn://192.168.1.101/account/trunk
.classpath
.project
·settings/
account-captcha/
account-email/
account-parent/
account-persist/
pom.xml
至此, Subversion 仓库就建立完成了,之后 Hudson就可以基于这个仓库运行集成任务。
4️⃣ Hudson 的基本系统设置
在创建 Hudson持续集成任务之前,用户需要对 Hudson 系统做一些基本的配置,包括 JDK安装位置和Maven安装等在内的重要信息都必须首先配置正确。Hudson 会使用这些配置好的JDK 及 Maven进行持续集成任务。如果要使用Ant 或者 Shell 来持续集成项目,Ant 或Shell 的安装位置也应该预先设置正确。
用户应该单击 Hudson登录页面左边的"系统管理",然后单击页面右侧的"系统设置"以进入系统设置页面,在系统设置页面,首先要配置的是 Hudson将使用的JDK 。
在页面中找到对应的部分, 然后单击 Add JDK 按 钮 ,Hudson 就会提示用户进行安装。Hudson 默认会提示自动安装 JDK, 用户可以看到一个 Install automatically
的复选框是被选上的,当单击"同意 JDK 许可证协议"并选择一个JDK 版本后 ,Hudson 就会自动下载安装相应版本的 JDK。
虽然这种方式非常简单,但往往用户在本机已经有可用的JDK, 而且不想花时间等待 Hudson去再次下载JDK。这时用户就可以取消选中 Install automatically 复选框,然后手动输入本机JDK的位置(往往就是JAVA_HOME环境变量的值)。
可以配置多个JDK, 当你的项目需要确保在多个不同版本JDK上都能正确集成的时候,这一特性尤为有用。
与JDK 配置类似,用户也可以选择手动或者自动安装 Maven供 Hudson 使用,还可以安 装多个版本的 Maven 供 Hudson 集成任务使用。还可以在页面上配置 MAVEN_OPTS 环境变量。MAVEN_OPTS环境变量用于设置Maven运行时的JVM参数。通过设置MAVEN_OPTS环境变量,可以为Maven构建过程中使用的JVM提供额外的参数和选项。
最后,别忘了单击页面下方的Save按钮保存系统设置。
5️⃣ 创建 Hudson 任务
要创建一个Hudson 任务来持续集成 Maven 项目,首先单击页面左边的新建任务,然后 就需要在页面右边选择任务的名称及类型。对于一般的 Maven项目来说,可选择的类型有 构建一个自由风格的软件项目 (Build a free-style software project)
和 构建一个Maven 2/3 (Legacy)项目(Build a maven2 project)
。前者不仅支持Maven项目,还支持 其他类型的构建工具,如Ant 、Shell。对于Maven 用户来说,两者最大的不同在于前者需要用户进行多一点的配置,而后者会使用Hudson自带的 Maven, 且从项目的 POM 中获取足够的信息以免去一些配置。除非你已经十分熟悉 Hudson, 推荐选择 free-style 类型。因为这种方式更可控制,当任务出现问题的时候也更容易检查。
输入任务名称,并选择 free-style 类型后,单击OK 按钮即可进入详细的任务配置页面。
5.1 Hudson 任务的基本配置
下面依次介绍 free-style 任务的各种配置。首先是项目的名称和描述。当Hudson 任务比 较多的时候,简洁且有意义的名称及描述就十分重要。
接着是一个重要的选项 Discard Old Builds。该选项配置如何抛弃旧的构建。Hudson每 执行一次构建任务,就可以保存相应的源代码、构建输出、构建报告等文件。很显然,如果每次构建相关的文件都保存下来,将会渐渐消耗光磁盘空间。为此,Hudson 提供两种方式让用户选择保留哪些构建任务的相关文件,它们分别为:
Days to keep builds
: 如果其值为非空的N, 就仅保留 N天之内的构建文件。Max # of builds to keep
: 如果 #非空,就仅保留最多 #个最近构建的相关文件。
还有项目使用的JDK 配置,这里可供选择的JDK 就是用户在系统设置中预先定义好的 JDK。
5.2 Hudson 任务的源码仓库配置
接着需要配置项目的源码控制系统。在项目配置页面的 Source Code Management
部分 , 选择 Subversion 单选按钮,然后在 Repository URL文本框中输入项目的 Subversion 仓库地址。 一般来说,该部分的其他选项保留默认值即可。
需要注意的是,如果访问Subversion 仓库需要认证, Hudson 会自动探测并提示用户输入认证信息。单击 enter credential
后 ,Hudson 会弹出一个页面让用户选择认证方式并输入认证信息。 输入正确信息之后,Hudson 就能读取仓库源代码了。
5.3 Hudson 任务的构建触发配置
再往下的 Build Triggers 部分配置的是触发构建的方式。可选的三种方式分别为:
Build after other projects are built
: 在其他项目构建完成之后构建本项目。Build periodically
: 周期性地构建本项目。Poll SCM
: 周期性地轮询源码仓库,发现有更新的时候构建本项目。Build when Maven dependencies have been updated by Maven 3 integration
: 当收到服务器内生成的其他项目的更新依赖关系通知时,安排此项目的新生成。这与"Notify that Maven dependencies have been updated by maven 3 integration"
的构建后操作协同工作。Build when Maven SNAPSHOT dependencies have been updated externally
: 在外部更新Maven SNAPSHOT依赖关系时生成。
例如,这对于在构建完成后运行广泛的测试非常方便。
如无特殊高级的需要, 一般不会选择第一种方式;而第二种方式显然会造成一些无谓的构建,如果几次构建所基于的源代码没有任何区别,构建的输出往往也就不会有变化; 第三种方式就没有这个问题,它能避免无谓的构建,节省持续集成服务器的资源。这种周期轮询源代码仓库的方式实际上也是最常用的构建触发方式。
既然是轮询,就需要配置轮询的频率, Hudson 使用了著名的 UNIX 任务调度工具Cron (http://en.wikipedia.org/wiki/Cron
) 所使用的配置方式。这种配置方式使用5个字段表示不同的时间单位(字段之间用空格或制表符分隔):
分 时 日 月 星期几
每个字段表示的意义及值范围分别为:
- 分: 一小时中的分钟(0~59)。
- 时: 一天中的小时(0~23)。
- 日: 一月中的日期(1~31)。
- 月:月份(1~12)。
- 星期几: 一周中的星期几(0~7,0和7都表示星期天)。
其中每个字段除了可以使用其范围内的值以外,还能使用一些特殊的字符:
*
: 星号表示匹配范围内所有值。M-N
: 连字符表示匹配M~N 范围内的所有值,如"1-5"。A,B,...,Z
: 逗号表示匹配多个值,如"0,15,0"。*/X 或 M-N/X
: 范围加上斜杠表示匹配范围内能被X 整除的值,如"1-10/3" 就等同于"3,6,9"。
下面一些例子可以帮助读者理解这种强大的配置方式:
* * * *
: 每分钟。5 * * * *
: 每小时中的第5分钟。*/10 * * * *
: 每隔10分钟。45 10 * * 1-5
: 每周一至周五的上午10:45。0,30 * 13 * 5
: 每月13号的每半小时,或者每周五的每半小时。
对于一个健康的项目来说,常见的做法是:每隔10分钟轮询代码仓库。
在配置轮询的时候,还可以使用 "#" 添加注释,此外空白的行会被忽略。例如:
bash
#check if there is any subversion update every 15 minutes
* /15 * * *
5.4 Hudson 任务的构建配置
接下来要告诉 Hudson 使用运行 Maven命令构建项目。单击Build 部分中的 Add build step
下三角按钮,然后选择 Invoke Maven 3
。
再选择一个安装好的 Maven 版本,输入Maven 命令 如 clean deploy 就可以了。需要注意的是,日常持续集成任务如果成功的话,都会生成快照版的项目构件。如果维护了一个Maven 私服,那么持续集成任务就应当自动将构件部署到私服中,供其他项目使用。这也就是这里的Maven 命令应当为 clean deploy 的原因。
至此, 一个 Hudson 任务基本配置完成,单击Save 按钮保存后就可以单击页面左边的 "立即构建" 来手动触发第一次集成。
6️⃣ 监视 Hudson 任务状态
Hudson 提供了丰富友好的图形化界面,让用户从各方面了解各个任务的当前及历史状 态,这包括整体的列表显示、自定义视图、单个任务的具体信息,如构建日志和测报报告 等。用户应该基于Hudson 提供的信息尽可能地将持续集成任务稳定在健康的状态。
6.1 全局任务状态
Hudson 的默认主页面显示了当前服务器上所有集成任务的状态。这个页面主要由四个部分组成:
- 导航莱单: 位于页面左上方,方便用户执行各类 Hudson 操作,如新建任务、系统管
理等。 - 构建队列:页面左边中间的部分,表示等待执行构建的任务。
- 构建状态: 页面左边下面的部分,表示正在执行构建的任务。
- 任务状态:页面右边的部分,显示了所有任务的状态。
下面重点介绍任务状态。在默认情况下,这里列出了 Hudson 中所有任务的状态,其中 的每一列从左到右分别表示任务当前状态、天气,名称、上次成功的时间、上次失败的时间、上次持续的时间以及左右一个立即执行的按钮(方便用户手动触发执行任务)。
其中需要解释的是当前状态及图中第一列 (S) 下的球形图标。Hudson 使用各种颜色 表示任务当前的状态:
- 蓝色: 任务最近一次的构建是成功的。
- 红色: 任务最近一次的构建是失败的。
- 黄色: 任务最近一次的构建表成功了,但不稳定(主要是因为有失败的测试)。
- 灰色: 任务从未被执行过或者被禁用了。
如果图标在闪烁,表示任务正在执行一次构建。
图中的第二列天气 (W) 也需要稍作解释。Hudson 使用一组天气的图标表示任务长期的一个状态,它们分别为:
- 万里晴空,任务80%以上的集成都是成功的。
- 稍有乌云,任务有60%~80%的集成是成功的。
- 乌云密布,任务只有40%~60%的集成是成功的。
- 阴雨绵绵,任务的集成成功率只有20%~40%。
- 电闪雷鸣,任务的集成成功率不到20%。
关于全局状态需要再次强调的是,当团队看到任务的集成状态不够健康时,应该尽快采取措施修复问题。
6.2 自定义任务视图
在一个稍有规模的公司或者组织下,持续集成服务器上往往会有很多的任务,Hudson 默认的视图会列出所有服务器上的任务,太多的任务就会造成寻找的不便。为此 Hudson 能让用户自定义视图,选择只列出感兴趣的任务,甚至还能自定义视图中显示的列。
用户可以单击默认视图 All
旁边的加号(+
)以添加 一个自定义视图。
我添加了一个名为xiaoshan-view 的任务视图,该视图仅包含account 一个任务,并且只显示状态、天气、任务名三列。用户可以根据自己的需要,选择要包含的任务和要显示的列, 甚至还能使用正则表达式来匹配要显示的任务名。
6.3 单个任务状态
在任务视图中,单击某个任务名称就能进一步查看该任务的状态。
图中包含了丰富的信息。左下角是构建历史 (Build History
), 该例中显示了最近2 次全部的构建,包括每次构建的时间。图下方还有3个永久连接,分别指向了 最近一次构建、最近一次失败的构建以及最近一次成功的构建。无论构建历史还是永久连接,我们都能单击某一个构建以了解更具体的信息。例如,单击图中构建历史中的 #2构建,就可以看到图示的内容。
请注意图左上角的导航信息,Hudson>account>#2 表示当前的位置是 Hudson 服务器下 account 任务的第2次构建。从图中可以了解到这次构建所发生的时间、相关的代码变更等信息。
需要指出的是,在图中左边的命令行输出链接。当构建失败的时候,了解这次构建的命令行输入至关重要。单击该链接后可以看到图示的页面。
还有一些链接包含了丰富的信息,例如最近变更集。单击该链接就能看到项目最近的代码变更。
除了变更集,还可以单击工作区,以图形化的方式查看该Hudson 从源码库取得的源码 文件及构建输入文件。
6.4 Maven 项目测试报告
图中还显示了项目的测试结果信息,为了获得这样的信息需要做一些额外的配置。
在前面文章中, maven-surefire-plugin 会在项目的 target/surefire-reports
目录下生成与JUnit 兼容的XML 格式测试报告, Hudson 能够基于这种格式的文件生成图形化的测试报告。
用户可以配置一个 Hudson 任务,在配置页面的 Post-build Actions 部分选择 Publish JUnit test result report
选 项 , 并且将 Test report XMLs
赋值为 * * /target/surefire-reports/TEST-*.xml
。
该表达式表示匹配任意目录下 target/surefire-reports/
子目录中以 TEST-
开头的 XML 文件,这也就是匹配所有 maven-surefire-plugin 生成的 XML 格式报告文件。
有了上述配置之后,就能在任务状态页面中看到最新的测试结果与测试结果趋势。
单击 Latest Test Result
就能看到最近一次构建的测试报告。在测试结果趋势图中,用户 也可以单击各个位置得到对应构建的测试报告。
用户还可以单击图中的链接得到更具体的测试输出,以方便定位并修复问题。
如果用户为一个 Hudson 任务配置了测试报告,就可以同时配置构建命令忽略测试。例 如,Maven 构建命令可以更改为 clean deploy -Dmaven.test.failure.ignore, 这样失败的测试就不会导致构建失败。也就是说,构建的状态不会是红色,同时,由于 Hudson 能够解析测试报告并发现失败的测试,构建的状态也不会是健康的蓝色。用户最终会看到 黄色的任务状态,表示构建不稳定。这种配置方式能够帮助用户区分失败的构建与不稳定的构建。
7️⃣ Hudson 用户管理
与一般软件的用户管理方式不同的是,使用Hudson 时,不需要主动创建用户,Hudson 能够在访问源码仓库的时候自动获取相关用户信息并存储起来。这大大简化了用户管理的步骤。
以前面建立的 Subversion 仓库为例,默认该仓库是匿名可读的,认证用户可写,不过我们并没有配置任何用户。现在要关闭匿名可读权限,同时添加一些用户。具体这里不涉及过多的配置细节,可以参考《Subversion与版本控制》 (http://svnbook.red-bean.com/
)一书。
首先,编辑 Subversion 仓库下 conf/svnserve.conf 文件中的 [general] 小节如下:
bash
[general]
anon-access = none
auth-access = write
password-db = passwd
这里的anon-access =none
表示匿名用户没有任何权限, auth-access =write
表示经认证用户拥有读写权限,而password-db=passwd
表示存储用户信息的数据位于同级目录下的 pass-wd文件中。再编辑 conf/passwd 文件如下:
bash
[users]
admin = admin123
xiaoshan = xiaoshan123
jason = jason123
这里为仓库配置了三个用户,等号左边是用户名,右边则是密码。
至此,就完成了一个简单的 Subversion 仓库用户权限配置。像日常开发一样,接下来在 Subversion 客户端分别使用这几个用户名对代码进行更改后提交至Subversion 仓库。例如, 对account-parent 模块的pom.xml 加入 developers 配置后,再使用如下svn命令提交更改:
bash
D:\svn\account>svn commit -m "add developers config" --username xiaoshan --password xiaoshan123
正在发送 account-parent\pom.xml
传输文件数据,
提交后的版本为2.
然后使用另外两个用户 admin 与 jason 分别对代码进行更改并提交, Hudson 会很快轮询到 Subversion 仓库内的更改,然后取得更改的代码信息,并了解到这些更改是由谁提交的。
待 Hudson 得到这些更改并触发集成任务之后,相关的 Subversion 用户信息就已经被 Hudson 存储起来了。单击 Hudson 页面左边的用户,然后就能在页面右边看到相关的用户信息,包括用户名、最近活动时间及相关的 Hudson 任务。
当然,仅仅知道用户名是不够的,还需要为用户添加详细信息,其中最重要的就是 Email地址,因为它将被用来发送邮件反馈。单击某个用户的名称(如 xiaoshan), 然后再单击页面左边的设置,在右边的用户设置页面中,可以配置用户的名称(不同于Subversion ID,该名称应该更容易识别人)、简要描述、个性化视图以及最重要的 E-mail地址。
单击Save 按钮后, 一个 Hudson 用户的信息就完整了。
8️⃣ 邮件反馈
持续集成中非常重要的一个步骤就是反馈。集成的状态信息(尤其是不健康的状态信息)必须及时地通知给相关团队成员,而最常见的反馈方式就是使用电子邮件。本小节介绍如何配置 Hudson来及时地发送集成反馈邮件。
首先需要做的是为 Hudson 配置邮件服务器信息。进入系统设置页面, 找到 邮件通知
部分,然后输入以下信息:
SMTP 服务器
: SMTP 邮件服务器地址。用户默认邮件后缀(Default user e-mail suffix)
: 默认用户邮件后缀。当用户没有配置邮件地址的时候, Hudson 会自动为其加上该邮件后缀。当用户数量很多,并且邮件地址都是一个域名的时候,该功能就显得尤其重要,例如配置后缀为@foo.com, 且用户 mike 没有配置邮件地址,那么当 Hudson需要发邮件给 mike的时候就会发送到 mike@foo.com。系统管理员邮件地址(System Admin E-mail Address)
: 系统管理员邮件地址,即 Hudson 邮件提示所使用的 发送地址。Hudson URL
: Hudson 服务器的地址。该地址往往被包含在电子邮件中以方便用户访问 Hudson取得进一步的信息,因此要确保该地址在用户机器上是可访问的。SMTP Authentication
: SMTP 相关的认证配置。
完整的邮件服务器配置如图所示。
配置完成后,可以单击图右下角的测试按钮,让 Hudson 发一封邮件至系统管理员邮件地址以确认配置成功。
接下来要做的是配置 Hudson 任务使用邮件反馈。进入任务的配置页面,然后找到最后 Post-build Actions
小节中的 E-mail Notification
复选框,将其选上。现在要关心的是两个问题:什么样的构建会触发邮件反馈? 邮件会发送给谁?
关于第一个问题,答案是这样的:
- 失败的构建会触发邮件反馈。
- 成功构建后的一次不稳定构建会触发邮件反馈。不稳定往往是由失败的测试引起的, 因此成功后的一次不稳定往往表示有回归性测试失败。
- 失败或不稳定构建后的一次成功构建会触发邮件反馈,以通知用户集成恢复到了健康状态。
- 用户可以配置是否每次不稳定构建都触发邮件反馈。
关于第二个问题,首先可以在 Recipients
中配置一个邮件列表(用空格分离), 列表中
的用户会收到所有邮件反馈。 一般来说,项目负责人应该在这个列表中。
其次, Hudson 还提供一个选项: Send separate e-mails to individuals who broke the build
。 当用户选择该选项后,邮件会发送给所有与这次构建相关的成员,即那些提交了本地构建代码更新的成员。Hudson 无法精确地知道到底是谁的代码提交导致了构建失败,因此只能通知所有与代码更新相关的成员。
典型的邮件反馈配置如图所示。
最后需要解释的是,图中的 Send e-mail for every unstable build
选项表示是否为所有的不稳定构建触发邮件反馈,如果不将其选中,只有成功构建后的第一次不稳定构建才会触发邮件反馈。推荐的做法是将其选上。敏捷高效的团队不应该忽略持续集成中的任何不健康因素。
9️⃣ Hudson 工作目录
到目前为止,本文都是从用户界面的角度介绍 Hudson 的各种功能。用心的读者可以想 象到 ,Hudson 的各种配置、任务、报告肯定是以文件的形式存储在磁盘中的。这就是 Hudson 的工作目录,了解该目录不仅能帮助读者理解 Hudson 用户界面中的各种特性,更重的是,读者需要明白怎样为 Hudson 分配合理的磁盘空间,长期运行的持续集成服务往往会 消耗大量的磁盘空间,理解哪些任务对应的哪些文件消耗了多少磁盘空间,对持续集成服务的维护来说至关重要。
默认情况下, Hudson 使用用户目录下的 .hudson/
目录作为其工作目录。例如,在笔者的 Vista 系统上,该目录为C:\Users\xiaoshan\.hudson\
, 而在 Linux 系统上,该目录为/home/xiaoshan/.hudson/
。 由于该目录会渐渐消耗大量的磁盘空间,因此用户往往会希望自定义该工作目录的位置,这时用户可以设置环境变量 HUDSON_HOME, 例如将其设置为 D:\hudson-work
。
一个典型的 Hudson 工作目录包含的内容的解释如下:
* .xml
: 这些XML 文件是 Hudson 核心及相关插件的配置,如config.xml
配置了全局的 JDK 、任务视图等信息,hudson.tasks.Maven.xml
配置了 Maven 安装信息 ,hudson.tasks.Mailer.xml
配置了邮件服务器信息,等等。war
: 如果用户独立运行hudson.war
, 那么其内容会被释放到该目录中后再启动。users
: Hudson 所存储的用户信息。userContent
: 用户可以将任意内容放到该目录下后通过 Hudson 服务页面的子路径访问,如http://192.168.1.101:8080/userContent/
。update s
: 这里存储了各类可更新的插件信息。plugins
: 所有 Hudson 插件都被安装在该目录而不会影响到 Hudson 的核心。jobs
: 该目录包含了所有 Hudson 任务的配置、存储的构建、归档的构建输出等内容。
本节稍后会详细解释该目录。
上述目录中最重要的可能就是jobs
子目录了,这里包含了所有Hudson 的任务配置、每
个任务的工作区、构建历史等信息。
jobs目录下有两个子目录 account 和 maven3, 它们分别对应了两个 Hudson 任务。每个任务都会包含如 config.xml 、nextBuildNumber 、scm-polling.log
等文件,其中的 config.xml 包含了该任务的所有配置,如 SCM地址、轮询频率等。
每个任务目录下会包含一个 workspace 子目录,这就是该任务的工作区。这里有最近一次构建所包含的源代码及相关输出。
任务目录下还有一个builds子目录,该目录包含了所有Hudson记录的历史构建,每个构建对应了一个目录,这些目录都是以构建所发生的时间命名的,如2010-04-15_14-56-08
,每个构建目录包含了一些文件记录其成功失败信息、构建日志、测试报告、变更记录等。如果用户为该任务配置了文件归档,那么每次构建归档的内容都会存储在archive子目录下。
可以想象,如果用户没有抛弃旧的构建,那么每次构建的记录都会保存在任务目录的builds子目录下。随着时间的推移,这些记录会消耗大量的磁盘空间,因此用户在使用Hudson的时候应该按照实际情况为其分配足够的磁盘空间,同时合理地抛弃旧的构建记录。
🌾 总结
本节关注的是持续集成。首先介绍了持续集成相关的概念,在此基础上,再引入最流行的持续集成服务软件------Hudson。Hudson非常易于安装,它与主流的版本控制工具都集成得很好,为了真实地体现持续集成场景,本文简略介绍了如何架设简单的Subversion仓库。使用 Hudson 创建持续集成任务会涉及很多配置,如JDK安装、Maven安装、源码库、构建触发方式、构建命令等,本文配以大量的图片以帮助读者使用和理解这些配置。任务创建完成后,还能从各方面了解任务的状态,包括成功与否、测试报告、源码变更记录等。Hudson还能够智能地收集用户信息,读者可以配置Hudson为用户提供邮件反馈。本文的最后介绍了Hudson的工作目录,以帮助读者更好地维护持续集成服务。
⏪ 温习回顾上一篇(点击跳转) :
《【Maven教程】(九):使用 Maven 进行测试------动态指定要运行的测试用例、包含与排除测试用例、测试报告、运行TestNG测试、重用测试代码 ~》