hudson持续集成即时反馈方案

1 持续集成、即时反馈与LavaLamp

即时反馈对于持续集成模式来讲非常重要。事实上，它是持续集成的精髓所在。当某一个CI构建任务出现问题时，应当将该失败信息即时反馈给相关同学（包括 RD、QA和其他关心代码CI情况的同学），以便触发者或其他依赖于该构建过程者及时改正或回滚代码，快速迭代解决问题。如果没有这样的即时反馈机制，仅 仅依赖于人工关注hudson等CI Server界面的话，会造成响应速度变慢且不可控，问题修复周期延长，进而破坏持续集成的有效性。

目前可用的持续集成即时反馈手段很多，包括Email群发、短信息群发、RSS订阅、GTalk通知，甚至Twitter消息等。其中一种令人耳目一新的解决方案是“LavaLamp”，即我们俗称的“神灯”。



图1：LavaLamp 神灯

LavaLamp本质上是一盏USB灯，放在一台靠近持续集成团队的台式机上，通过安装对应的CI Server插件，能够使用不同的颜色显示指定持续集成任务的当前状态（譬如红色表示失败、黄色表示部分失败、绿色表示成功）。此外它还能在持续集成任务 失败或部分失败时，以警报声（Beep）的方式引起注意。LavaLamp还能活跃团队气氛，让持续集成实践团队处在一种比较酷的氛围中，进而调动其成员 解决问题的积极性。百度的Ecom部门目前已经有产品线采用了商业化LavaLamp解决方案，在持续集成过程中使用效果不错，但需要一些资金投入。

毛主席教导我们：“要多快好省地建设社会主义”，而邓小平同志也教导我们：“不管黑猫白猫，逮着老鼠就是好猫”。

因此，本文将基于hudson平台（现在已经改名为Jenkins了）探讨一种免费的持续集成即时反馈解决方案，能达成与Lavalamp 神灯同样甚至更好地视觉和听觉效果，再通过配合其他的即时反馈手段（譬如百度HI群），实现有百度特色的持续集成之路。

2 让显示器客串Lavalamp

Lavalamp的思路其实很简单：把持续集成构建任务的状态暴露在大众视线之下，而不是湮没在CI Server或浏览器中。只不过其实现是基于特定设备（USB灯及其控制器），需要投入一些成本。

那么，有没有免费的的视觉效果解决方案呢？当然有！那就是咱们——显示器。

事 实上，hudson官方网站上已经提供了一个非常好的插件，名叫Extreme Feedback Panel（简称XFPanel，http://wiki.hudson-ci.org/display/HUDSON /eXtreme+Feedback+Panel+Plugin）。顾名思义，该插件提供了一种特殊格式的hudson视图，当在浏览器上访问该视图时， 它会将视图内各个Job的当前状态以醒目的方式显示出来。如果使用浏览器的全屏功能（按F11切换），就能达到如下图所示的效果：



这样，咱们工位上闲置的LCD显示器就能成功客串为LavaLamp 啦。而且LCD显示的信息要比LavaLamp多得多。后者只能通过颜色变化提示，而大家无法获知是哪个job挂了，具体信息还是得上CI界面上查看。而 通过XFPanel插件，团队成员能一目了然各个Job的当前状况，甚至还能获知是谁commit代码引发了问题，以及QA的Quick Test Case失败了几个，这样更能体现持续集成的速度优势。

那么，该如何使用该插件呢？

首先，请从hudson官方网站下载XFPanel插件为.hpi文件，并在hudson的插件管理界面导入该插件，当然别忘了重启hudson服务器。这个过程本文不再赘述。

然后，点击新建视图，并选择视图类型为“eXtreme Feedback Panel”，如下图所示：



接下来，点击OK，在视图设置界面进行配置。如下图所示：



上述设置完毕后，该Extreme Feedback视图就算搞定了。请切换到该视图上，然后按F11键，将浏览器窗口切换到全屏。此外，你还需要在Windows中设置为“从不关闭显示 器”和“从不休眠”，并关掉屏幕保护程序（如下图所示）。最后，把显示器放在大家都能看到的高处。于是一台功能强悍的显示器版LavaLamp就诞生啦。



与Lavalamp相比，使用显示器的好处是成本为0，且提供的信息更为丰富，界面也更为醒目。当然，由于显示器的耗电量要比lavalamp大，因此建议践行该方法的CI团队多去开展植树活动，消除由此带来的碳足迹。

3 让音箱发出任务失败报警

仅 仅由LCD显示器显示出持续集成任务的状态信息还是不够的，因为在工作时大家都很投入，保不准就能及时看到显示器上那大大的红色感叹号。在成熟的解决方案 中，当关注的持续集成任务失败或者部分失败时，LavaLamp应当随即发出“嘟——嘟——”的报警音频，敦促责任人马上着手解决问题。 而上一节介绍的XFPanel并没有提供这样的音频功能。

Hudson官方网站上也提供了两个插件来尝试解决该问题，分别叫做 Hudson Sound 和 Hudson Speak。 二者都是在Job的Notify阶段设置，所不同的是，前者能播放提前准备好的.wav音频，而后者则通过TTS技术将一段文本读出来。

这 两个插件虽然很酷，但都要求将hudson服务器安装在一台拥有声卡设备的服务器上，并且最好是Windows服务器（因为Linux服务器即便有声卡， 其驱动情况也过于复杂）。当播放报警音频时，这两个插件都只能在Hudson 服务器本机上播放。也就是说，必须将Hudson服务器搬到工位附近，而不能放在机房里。

但在目前百度办公网环境中，这样做是不靠谱的，有如下理由：

※办公网中的Windows机器没有域名，访问不便。

? ※ 放在工位上的服务器很容易断网、IP失效甚至断电，让CI服务的稳定性无从谈起。

? ※ 所有办公网中的计算机都访问机房都要通过IDC机房隔离，且需要BNAC系统准入，在端口上有层层限制。

因此，直接使用Hudson音频插件是此路不通的。需要另行寻找其他解决途径。

通过多次摸索和实验，基于Hudson提供的Post Build Task插件（主页为 http://wiki.hudson-ci.org/display/HUDSON/Post+build+task），我们有了一个解决方案。
Hudson Post Build Task插件安装后能在Job配置页面最后添加一套“Post Build Task”流程。该流程能在Job结束前检查STDOUT输出日志内容，通过一些指定的字符串进行匹配。当满足给定的字符串匹配条件时，就会触发执行指定 的脚本。

因此，这里我们的思路如下： 通过Post Build Task插件监视持续集成任务输出中有没有“Build Fail”字符串，若出现该字符串，说明构建失败，则远程通过slave.jar运行上一节显示器所述台式机上的一段脚本发出报警声。

具体做法如下：

? · 第一步：请下载和安装Post Build Task插件，并重启Hudson服务器（这里不再赘述）。

? ·第二步：请将上一节客串Lavalamp的显示器所属台式机（这里简称其为“公告机”）加入Hudson节点池中。建议使用JNLP方式启动其Slave.jar（这里也不再赘述如何添加windows节点）。



·第三步，请创建一个负责发出报警声的Hudson任务，名为“BuildFail_Notice”。该任务的功能非常简单——绑定到上述“公告机”，并触发windows的录音机程序播放事先准备好的.wav格式报警音频



上述命令中，录音机的可执行文件路径为C:\WINDOWS\system32\sndrec32.exe， 在命令行下执行时。使用/play参数表示播放指定文件，使用/close参数表示播放完毕后退出录音机程序，而通过/embedding参数来表示后台 方式执行，即不在Windows界面上显示录音机程序，以免影响持续集成XFPanel视图。

请注意，这里的build step类型应当是Windows Batch脚本。

完成本步骤后，请将准备好的.wav文件放在公告机的c:\BuildFail.wav路径处，然后手工触发该任务，调试一下，看是否能发出报警音频。

·第四步，在各个需要失败报警的Hudson任务中，增加Post Build Task步骤，其意图是：当匹配到Build Fail或其他能表征Job失败的日志时，就通过Hudson CLI命令行方式调用第三步准备好的失败音频报警任务。其Post Build Task配置如下图所示。其中：

?* 需要提前将hudson-cli.jar包放到各个Hudson Slave节点上去，该Jar包在hudson.war中可以找到；

?* 调用hudson-cli.jar包时，-s参数表示hudson服务器的URL地址，请根据自己部署hundson环境的实际情况填写

?* 调用hudson-cli.jar包时，使用build参数表示要构建一个任务，后面跟着被执行的任务名。在这里要执行的就是负责发报警音频的BuildFail_Notice任务。

?* 在这里，你还可以配置更多的字符串匹配条件，并通过AND或者OR关系将他们组装起来，成为一套更复杂的触发条件。此外，还能为不同的触发条件触发不同的脚本，譬如为Fail的任务触发一个声音，再为Unstable的任务触发另一种声音。



完成上述四个步骤后，一套不花一分钱的音频触发解决方案就搞定了。该方案看上去有些复杂，但设置起来其实一点也不麻烦。而且，其灵活性非常强，譬如：

? #你可以录下自己的声音作为持续集成报警音

? #你可以为不同的持续集成任务提供不同的报警音，这样光听到声音就知道是哪个任务挂掉了

? #你可以为同一个持续集成任务的不同状态触发不同的报警音，这样听声音就知道该任务是哪个失败状态了

? #你可以为某个特定的字符串触发报警音，而不仅仅局限于任务失败场景，譬如当执行Case成功率低于50%的时候再发出报警

? #等等…… 总之，只有想不到，没有做不到！

你或许要问，为什么不能直接使用远程调用的方式触发windows发报警音呢？You are right，通过SSH、Python rpyc乃至自己手写Daemon的方式来远程触发播放报警音频看上去更为直截了当，但在实践过程中会碰到问题，那就是“IDC隔离”。

所 谓IDC隔离，是将百度办公网段和服务器网段隔离开来，从办公网只能访问服务器网段的有限范围的端口，而从服务器网段则能访问办公网段的任意端口，即单向 端口隔离。这样就带来一个问题：目前Hudson服务器是位于服务器网段内的一台Linux服务器上，而负责播放失败报警的Windows台式机则位于百 度大厦的办公网段中。以SSH远程调用为例，当从Hudson服务器直接发起SSH请求到这台windows台式机时，根据Socket基本规 则，Hudson服务器访问的是Windows台式机的22端口，而后者则访问前者动态分配的端口。这个动态分配的client端口范围是无法限定的，基
本不会落在IDC隔离所允许的端口窗口范围内。因此，造成从Linux服务器直接向办公网台式机发远程调用请求会失败。

而Hudson的slave.jar机制不存在上述问题，因为Slave.jar是主动去连Hudson服务器的指定端口的，只要将hudson服务器的监听端口设置在窗口范围内，则各个节点的Slave.jar就都能连上去并执行hudson要求的任务。

综上所述，我们不得不舍近求远，采用了一个看似曲折，实则曲径通幽的解决方式。

4 后话

其 实即时反馈的方式有很多。譬如最简单的就是群发邮件。此外还可以通过即时通信软件、安装在桌面上监听软件、手机、RSS订阅等方式实现任务状态的即时广播 提醒。你可以根据自己的需求，安装对应的hudson插件来使用这些功能。这些插件可在hudson官方网站找到，URL 为：http://wiki.hudson-ci.org/display/HUDSON/Plugins#Plugins- Buildnotifiers

但这些解决方案中，都没有提到咱们百度人每天必用的Baidu HI，也不包括QQ等国产IM软件。有志于hudson插件的同学可以考虑为这些国产IM软件开发对应的插件，让咱们的IM软件业去露露脸。

其实除了插件之外，我们也可以通过其他方式来在Baidu HI群上自动发出任务状态通知。大体思路是：

? ·step1：为某一项目的持续集成专门注册一个baidu hi账号，并加入该项目的hi群

? ·step2：基于Sikuli或Watin或其他Web端自动化工具，编写一段脚本，访问http://web.im.baidu.com/，用该账号登陆并发送通知到项目Hi群中

? ·step3：使用Post build task插件，当匹配到符合条件的情况是，调用step2的脚本，访问网页版百度HI发出通知消息。 如果服务器无法直接访问外网，可参考前面解决音频问题的思路，将该脚本调度到办公网环境的一台台式机上运行。

总而言之，在持续集成的道路中，只有想不到，没有做不到。同学们，发挥你们的聪明才智和创造力，让我们的持续集成之路走得更加意气风发，更加乐趣无穷！