使用Hudson进行持续集成(二)

要运行您新近创建的作业，第一步就是跳转到http://localhost:8080/hudson(Hudson 控制面板)。图20显示了我在Ubuntu服务器上设置的全新的Hudson实例。
 

 图20. Hudson 控制面板

    在截屏的中心部分，您可以看到我刚刚定义的HeliosJMXTrunk 作业。当然这个截屏上还有其它一些很值得我们关注的条目：

• 灰色球体状图标描述着作业的一种状态。灰色这种情况表明当前作业从来没有被构建过。
• 在左边的表格中，名称为"Build Queue"的标签会显示当前正在运行或者准备运行的作业。表格中名为"Build Executor Status"的标签会公布已分配构建线程的状态。Hudson默认情况下会分配两个用于构建的线程，这意味着Hudson可以并行的执行两个构建。如果要修改它的数量，您可以单击Manage Hudson ，然后修改(1.3以后 # of executors)Configure Executors。请小心使用这个数量，因为软件的构建往往会相当密集的消耗内存资源；把太多构建同时加载到Hudson服务器是不合理的做法，因为这反过来可能会减缓您所有作业的执行效率。
• RSS订阅图标。Hudson提供了另一种事件通知的方式：RSS订阅，包含整体系统的订阅和单独作业的订阅，主要有如下几种情况：
  
  •  成功的构建
  •  不稳定的构建
  •  被终止的构建
  •  SCM的改变

接下来请求一次构建，您可以点击作业列表表格中最右侧的构建图标。当然，您也可以单击当前作业的名称，它将指向您当前作业的主页，然后单击Build Now链接按钮。

当作业一旦运行，您将会看到这个作业正在队列中的仪表板和当前工作主页上运行。这两种显示如图21 。

 

图21. 当作业运行时两种不同的显示

 

      一般来说，您想在某些时候以通过视图输出作业的运行来监控当前作业的进展情况。为此，您链接到作业主页，单击Console Output。如果工作已完成，这将显示构建脚本产生的静态输出，;如果作业仍然在运行中，Hudson将不断刷新网页的内容，以便您可以看到它运行时的输出。图22 描述了这个非常有用的功能。

 

图22.  控制台以直播方式显示作业运行时的输出

一旦构建完成后，完成后的作业将会有三个地方进行显示。

• 你可以在Hudson的控制面板上看到它，如图23 。
• 你可以在当前作业主页上看到它，如图24 。
• 通过点击构建历史中某个具体的构建链接，您就能跳转到Hudson为这个构建实例而专门创建的构建主页上。如图25。

 

  图 23.  Hudson控制面板上显示已完成的作业

 

     下面简要介绍控制面板中符号的意义，它描述了“作业状态”这一部分，黄色球标意味着构建成功，但被认为不稳定。W栏目代表着“天气”，这里的小太阳图标表示阳光普照。因为构建成功了而且没有任何处理插件(如上面所述的插件)来通知Hudson报告任何糟糕的情况。当然值得一提的是，最近一次构建花费了15分钟。这是因为我为测试套件中的一些单元测试时使用了一些调度组件，故意使运行时间延长了。把实际构建和测试在当前作业分隔开来运行其实是一个很好的选择。

 图 24.  当前作业主页上显示已完成的作业

 

     当前作业主页上还包含了一些有趣的条目。左侧栏的链接主要控制作业的配置(为了修改你在New Job后的定义)、删除作业、构建作业。右边部分的链接指向最新的项目报告和构件。

 

 

图 25.  当前构建主页的已完成构建

    构建主页是针对一个构建实例而特设的。请注意，Hudson会分配一个内部的版本号用于跟踪分布式构建。此网页还列出Subversion的最新修订(没有在此次构建上的)，同样还有三个失败的JUnit测试案例。这三个失败就是导致Hudson认为此次构建不稳定的原因，这说明该次软件构建并没有错误，只是有单元测试失败了。接下来的构建中，如果没有了任何单元测试错误的话，在控制面板和工程主页将显示一次稳健的构建。如图26中截屏所示。

 

 图 26. 二次构建后的控制面板和作业主页

 

    我现在已经涵盖了作业的配置、作业的启动以及请求一次即时构建所必须的步骤。接下来我们简单的讨论一下在Hudson中如何描述一个作业的状态。

作业状态

     在上面展示的截图中，您将注意到有两个图标描述当前作业的状态。Hudson使用两个概念来介绍一个作业的总体状况：

• 作业状态:  图27中分级符号概述了一个作业新近一次构建会产生的四种可能的状态：
  • Successful: 完成构建，且被认为是稳定的。
  • Unstable:    完成构建，但被认为不稳定。
  • Failed:  构建失败。
  • Disabled: 作业已禁用。

• 作业稳定性: 当一个作业中构建已完成并生成了一个未发布的目标构件，如果您准备暗中评估此次构建的稳定性，Hudson会基于一些后处理器任务为构建发布一个稳健指数(从0-100 )，这些任务一般以插件的方式实现。它们可能包括单元测试(JUnit)、覆盖率(Cobertura )和静态代码分析(FindBugs) 。分数越高，表明构建越稳定。图28中分级符号概述了稳定性的评分范围。任何构建作业的状态(总分100)低于80分就是不稳定的。

 

图 27.  作业状态

图 28.  作业稳定性

构建轨道

      Hudson允许您创建多个构建轨道；根据您的软件开发过程，您可能希望依据软件项目创建一个以上的构建轨道。构建轨道是针对一个具体的项目或产品的构建作业，它们都具有独特的配置。区分构建轨道的因素可能是当构建作业在同一个项目中从SCM的不同分支获取源代码；另外，在执行同一份源代码时，不同的轨道也可以处理不同的任务。其中，在具有相同逻辑的软件项目中可能直接影响你创建不同的构建轨道的有：

• Source control branches: 为了更干净利落地支持多版本源代码的并行开发，许多开发团队会在其源代码控制系统保持了一系列的分支。诸如此类情况，有必要在Hudson中为每个分支基础上的开发建立一个单独的构建轨道。同理也可以建立一些较旧的不活跃的分支，以便把软件的老版本进行归类，这样一来也可以很容易地重建。以下的程序您就可能需要创建单独的分支：
  • 基于主干的构建: 这是个新近的、活跃的、频繁修改的源码基线。
  • 基于发布的构建:  致力于持续发布而单独创建的分支，其中的源码通常是稳定的，但是主干开发可继续转换未来的发布。
  • 基于修复Bug的构建:在主线开发活动中孤立一个Bug以便修复它而单独创建的分支。
  • 实验性构建: 为了在源码基线上测试实验性的想法而单独创建的分支，可能最终不会聚合到主线上的代码。
• Build job task categories: 为不同源码进行构建可能需要不同的设置或者序列化构建任务，这一般视指定分支的当前状态或者活动情况而定。例如，以下的程序您就可能需要创建单独的分支:
  • 简单建立核查作业，当您不需要考虑构建的稳健性而仅仅想要定期核实代码能被构建，然后产生可用的构件。
  • 构建并核实构建的稳定性可能略低于平常的指标，就从源代码和构建后的构件中构建构件和执行一个完整的测试流程。
  • 发布候选作业，执行完整构建和稳健性测试流程，然后完成一系列任务以提供可交付的发布产品。
  • 执行完整发布作业，当一个候选发布版准备分发并自动地把打包后的构件上传到一个公共的库，以及任何其它必须的任务以便完成一个完整的发布。
• Deliverable considerations:  即便是完全相同的代码分支和构建任务，您也可能需要采用稍微不同的工具以支持构建。例如，您可能需要根据类Java 1.5和Java 1.4 发布单独的版本。

图29描述了一个源代码控制分支和对应的Hudson构建轨道的合适的逻辑结构。

图29. 源代码控制分支和对应的Hudson构建轨道

        Hudson能够很容易地复制一个现有的作业从而创建一个新的作业。为此，您需要浏览到Hudson的控制面板，单击New Job 链接。输入新工作的名称，然后选择Copy existing job。请注意，当您开始输入时，Hudson将会把现有的作业填充到一个列表框，您可以在此复制符合您所输入的内容。然后单击OK，这样就创建了你的新作业。图30描述了这个过程。

图 30.  拷贝现有作业从而创建一个新的作业

      一旦您通过这样的方式创建了一个新的作业，除了名字之外它实际上只是您当前作业的副本，所以您会想到通过修改选项从而修改这个新拷贝。例如，您想要：

• 当某个工作区迁移后更改源代码控制目标分支。
• 修改构建脚本或者构建脚本目标，并通过Hudson执行。
• 修改系统属性，并通过Hudson传递到您的Ant脚本里。

使用视图

      当您创建一些构建轨道后，您可能发发现您的控制面板已经成为了一个有点杂乱无章的长串作业列表。一种可取的做法就是，以创建视图的方式重组控制面板。一个面板视图包含一组相关的作业，您可以在控制面板上定义一个单独的标签以供显示。当为相关的作业创建视图组时，您就会理解到实施一致的作业命名约定是多么有益了。

      要创建一个视图，单击控制面板中标“+”的小标签。在新的视图页面，输入新组的名称和一个可选的描述信息。Hudson将在当前每个作业配置一个的标记复选框，因此您就可以在视图中包含想要的作业了。

      然而，在我看来还有一种更好的方式来组织作业。单击标记为Use a regular expression to include jobs in the view的复选框，它提供一个正则表达式，在您想要的作业中匹配名称。这对于作业遵循了一致命名约定来说就很方便。您可以按一般的软件项目归类，或者按可能的构建类型作为作业组来配置视图。我已采取了后一种做法，如图31。我在那里建立了一个名为“Release Builds”的视图，其中包括所有包含" release "关键字的作业。

图 31.  创建一个新的面板视图

     使用正则表达式归类的办法还有其它优势，就是在新作业被创建后，它们将会按作业名称匹配的方式自动地添加到相关的视图中，但是原来指定方式选择作业的视图则需要手动更新。

     图32显示了基于构建类型的新近组织过的面板。

图 32.  按构建类型的面板视图

Hudson 插件

     由Hudson类库现有的Hudson功能性扩展和开发者们为Hudson提供的新功能都可以称之为Hudson插件。有些插件可以无缝添加到您的构建过程，然而其它，诸如除CVS和Subversion的SCM插件则需要实现与源代码控制系统的支持，从而有必要使用Hudson完成您的安装。

    目前有许多可用的插件，因此我就不在这里一一列举了，但这些插件总的来说有如下类别：

• SCM: 除CVS和Subversion外需要实现与源代码控制系统支持的插件。

• Triggers: 事件监听并触发构建的插件。例如，URL改变触发器将监控一个URL；当地址内容发生改变，这个触发器就将执行一次作业。

• Build tools: 实现额外构建工具的插件，如MSBuild和Rake。如果您想在Hudson中构建非Java的软件时这些就特别有用。

• Build wrappers: 通常涉及时执行在受控制的构建过程本身之前和之后事件的插件。例如， VMware插件将在构建之前启动一个客户虚拟机，建立和然后在构建完成后关闭它。这在您可能需要访问VM以执行单元测试的情况下是非常有用的。

• Build notifiers: 这些插件是做为作业事件发布通知的替代方式--通过Twitter 、IRC、谷歌日历活动等等。

• Slave launchers and controllers: 这是Hudson中一个非常强大的功能，本文中没有解释从机Hudson实例扮演主机Hudson实例工作。目前在这个类别中只有一个插件：SSH从机插件，它允许从属来管理超过一个SSH的链接。

• Build reports:  这一系列插件主要是在用您的源代码或者构件进行一些分析的基础上创建有用的报表。例如，Cobertura 插件总是通过您的构建脚本增量统计覆盖率。

• External site integrations: 以协助Hudson整合与其他应用程序的插件，如Jira或Bugzilla 。

• Artifact uploaders: 以协助您把构件发布到一些网络终端的插件，如java.net版本库或一个FTP服务器。

• Page decorators: 为Hudson网页增加一些美化或者有用的装饰物，比如在Hudson中增加谷歌跟踪服务以跟踪其所有网页的谷歌分析插件。

        Hudson 插件管理器允许您安装新的插件，和更新您Hudson服务器上的插件。管理者将连接到联机资料库，检索可用的和已更新的插件。如果您的Hudson服务器无法直接连接到外部资源，您可以从Hudson网站上下载您想要的插件。点击网站上的plugins文件夹，您将看到一个可用的插件列表。这独特的插件文件以.hpi 作为扩展名。一旦您下载了该插件，复制它到Hudson主目录下的插件子目录。(Hudson主目录被称为.Hudson，将在用户的主目录下运行Hudson服务器。)一旦文件被复制，您将需要重新启动Hudson才能使插件生效。使用Hudson插件管理器，单击控制面板上的Manage Hudson链接，然后点击Manage Plugins。插件管理器显示在图33中，它包含四个标签：

• Updates: 清单中列示了Hudson为某些插件搜索到了可用的更新。列出的每个插件可以被选择并应用更新。
• Available: 清单中列示了可用于安装（而不是目前已安装的）的所有插件 。列出的每个插件都可以被选择并安装。
• Install:  清单中列示了已经安装的插件。
• Advanced: 允许您通过设定HTTP代理的方式使Hudson与在线插件库建立连接。此外，还提供了一个上传设备，可以安装你在Hudson以外已下载的那些插件。

图 33.  Hudson 插件管理器

      一旦您想要的插件已经安装或者已更新，Hudson需要重新启动才能使它们生效。如果您使用的服务器是JBoss，请注意，您可以通过修饰JBoss的部署目录下的hudson.war已恢复到您原来的已部署的状态来做到这一点。 （在更新一个文件的时间戳时，修饰是一种很实用的功能。） 这会导致JBoss重新部署Hudson服务器，从而达到重新启动的相同效果。

 

      了解某些类型的构建报告插件的一种重要的概念是，它们并不一定为你产生很精髓的报告。相反，它们歹为产生的增量报告而处理额外一些的任务；在某些情况下，它们会把您产生的报告重新格式化到本地Hudson的综合报告中。 例如， Cobertura插件必须依赖于您的构建脚本必须实现检测您的目标测试类、执行单元测试、并生成详细构建覆盖率报告的一系列工序。接着插件更新正在运行的历史趋势的覆盖率报告，以便使您可以随着时间的推移查看覆盖率的变化。在图34中描述了一个这样的趋势报告的样例。

图 34. 单元测试、静态代码分析、代码覆盖的历史趋势

      此外，JUnit测试结果和FindBugs的插件例子将创建Hudson本地报告并显示在作业或构建实例的主页上。 （JUnit插件实际上已经存在并且无需安装。 ）图35是通过FindBugs插件产生内置的报告并显示构建实例主页上的一个例子。

图 35. 一次构建后的FindBugs即时报告

     您可以实现您自己的插件，以提供你能想到的几乎任何类型的Hudson扩展。如果您有兴趣这样做，你可以在Hudson  Wiki找到参考、文档和教程（见下面的资源部分）。

总结

     以上就是我介绍的Hudson持续集成服务器。我想你将会发现它是一个很好的软件；多亏它的易于安装和配置，你可以体验一下它的启动和运行的速度有多快。 基于java.net网站有活力的书籍中使用Hudson开发项目的主机情况，Hudson很明显具有越来越多的趋势。我粗略地浏览了邮件列表，表明人们接受了调查并且一贯和迅速的做出了反应，但我必须补充，这段时间我一直在使用它，我也没有遇到任何问题以促使我寻求支持。我希望你会喜欢并探索Hudson--签出资源部分下面的更多文章，下载及相关的链接。