级别： 初级 Paul Duvall, CTO, Stelligent Incorporated
2006 年 12 月 14 日 反馈对于持续集成（Continuous Integration，CI）实践来说至关重要，事实上，它正是 CI 系统的“生命血液”。快速反馈则能够实现对需要引起注意的构建事件的及时响应。没有了诸如电子邮件或 RSS 等反馈媒介，处于中断状态的构建就有可能继续处于中断状态，这就破坏了 CI 的初衷！在
让开发自动化
的这一期文章中，自动化专家 Paul Duvall 介绍了能够合并到 CI 系统中的各种反馈机制。
当我向那些还没有使用过这项实践的技术专家们描述 CI 时，我常常会侧重于它的主要优点之一，即它可以缩短故障出现到故障解决之间的时间。实际上这项优点正是 CI 服务器可以对构建状态进行快速反馈这一功能的直接结果。在我看来，对构建事件的快速反馈是 CI 服务器的中心原则，这也是许多人将 CI 系统描述为持续反馈机制的原因所在。
一个构建发生故障时，我希望能够立即知道这一情况，以便就能够采取适当的行动来解决这一问题 —— 不论那是编译错误、测试故障甚或是整体复杂性的增加。对问题了解得越迅速，获取的信息就越相关，解决问题的时机也就越有利。
然而，反馈的目的是为了采取行动。而在 CI 中，这个行动必须迅速，因为构建中断会影响到每一个人，因而由 CI 服务器部署的反馈机制也必须及时。还好，如今大多数（如果不是全部）可用的 CI 服务器都提供电子邮件反馈机制；当然，还有非常多其他的媒介可供选择，比如 Really Simple Syndication（RSS）提要、SMS 文本消息以及 X10 设备。这些反馈机制能够及时协助有关人员迅速采取行动。
 |
关于本系列
作为一名开发人员，我们的工作就是为用户将过程自动化；然而，我们当中有很多人却忽视了将我们自己的开发过程自动化的机会。为此，我编写了让开发自动化 这个系列的文章，专门探索软件开发过程自动化的实际应用，并教您何时以及如何成功地应用自动化。
|
|
以电子邮件方式执行
电子邮件非常普遍，这让它成为了一种简单实用的反馈手段，我所熟悉的每种 CI 服务器都提供一定类型的电子邮件反馈机制。事实上，大多数 CI 服务器都基于所需的构建事件提供配置谁接收到哪条消息的功能。例如，技术主管也许需要经常收到电子邮件而不管构建状态如何，但项目经理通常只需要在构建失败时收到电子邮件。而负责将代码签入到 CM 系统（因此触发一个 CI 构建）的开发人员则需要收到提示构建状态的电子邮件。
清单 1 是 CruiseControl 主配置文件（config.xml）的一个例子，配置该文件是为了以 HTML 格式将成功构建及失败构建的电子邮件发送给该项目的“构建的主人” 。
清单 1. 用 CruiseControl 发送电子邮件
<publishers>
<htmlemail
mailhost="localhost"
defaultsuffix="localhost"
username="bfranklin"
password="G0Fly@Kite"
returnname="Buildmaster"
returnaddress="buildmaster@localhost"
subjectprefix="[CC]"
xsldir="webapps/cruisecontrol/xsl"
css="webapps/cruisecontrol/css/cruisecontrol.css">
<always address="buildmaster@localhost"/>
</htmlemail>
<publishers>
|
也可以使用 CruiseControl 的电子邮件任务的 defaultsuffix 属性将电子邮件发送给对构建进行过最近的更改的一个或多个开发人员。
图 1 是基于清单 1 中的配置一个用户可能收到的电子邮件样例。
图 1. CruiseControl 方式下关于构建状态的电子邮件样例
对于使用 CI 的项目，电子邮件毫无疑问是其事实上的标准反馈机制，但是如果团队成员收到太多的电子邮件，他们就会开始忽略这些邮件，这当然会破坏反馈机制的初衷。我发现这样做会更加有效，即将 CI 系统配置为只向那些将最近的更改应用到代码库的开发人员以及不介意每天接收到大量关于构建状态的电子邮件的项目主管发送电子邮件。
|
什么是持续集成？
持续集成（CI）是一种实践，可以让团队在持续的基础上收到反馈并进行改进，而不必等到开发周期后期才寻找和修复缺陷。诸如 CruiseControl 之类的检查工具是在后台运行的，它们轮询版本控制存储库，从中寻找更改之处。例如，当发现某一更改时，这类工具就会通过 Ant 执行预定义的构建脚本。持续集成的实践为持续检查提供了便利。
|
|
用 RSS 来求援
RSS 既是被动的也是主动的反馈形式，由于这种反馈机制减少了接收到的电子邮件消息的数量，因而更加吸引人。RSS 提要是一份生成的 XML 文件（符合标准），该文件基于某些事件进行更新。RSS 阅读器随后获取此更改并创建一条指示新内容的被动的消息。因而，如果您不愿意被大量的电子邮件所困扰，可以改用这种方式。
在 CI 系统中，可以基于最近的构建状态对这个 RSS 提要进行更新。例如，图 2 是默认状态下为任何构建事件生成的 CruiseControl RSS XML 中的一个例子。
图 2. 来自 CruiseControl 的 RSS XML
将您手边的 RSS 阅读器指向这一提要，当发生新的构建事件，RSS 提要更新时，您就会得到相应的通知。图 3 显示了在 RSS 阅读器中显示的 RSS 提要：
图 3. RSS 提示有错误出现！
加入 SMS
如果您不在计算机前而构建失败了又如何呢？如果保证集成构建的成功是项目的首要事情之一，那么就需要实时了解构建状态。保持与构建状态同步的一种方法是通过短消息服务（SMS），即向手机发送短文本消息。
幸运的是，和发送电子邮件相同的机制也可以用来发送 SMS 文本消息。例如，清单 2 显示了一个使用 CruiseControl 电子邮件任务发送 SMS 消息的例子：
清单 2. SMS 样例代码
<publishers>
<email mailhost="localhost"
returnaddress="buildmaster@localhost"
returnname="Buildmaster"
reportsuccess="fixes"
subjectprefix="brewery"
buildresultsurl="">
<failure address="7035551212@vtext.com"/>
</email>
</publishers>
|
|
为什么有这么多反馈机制？
使用 CI 时，对中断构建的处理在重要程度上是最高的，一般来说团队都不会移做其他任务（而会一直处理故障）直到集成构建再次成功。因而，选择多个服务于不同目的的机制通常十分必要，例如 SMS 非常适合经常不在计算机旁的人们，而 X10 设备则能够让构建状态一目了然。在一个单个的项目中，使用我在这里提到的所有反馈机制反而会降低效率。因此需要选择最适合您的机制并不时地改变一下，这甚至可以给项目添加一些趣味。
|
|
我用这样一种方式配置了清单 2 中的电子邮件任务，即只在构建失败时接收文本消息，这是减少 SMS 消息的一种有效手段。另外，e-mail 任务的 reportsuccess="fixes" 属性表明当完成构建后，将收到一份后续的文本消息。
图 4 是构建失败时 CruiseControl 服务器发送出的消息示例。
图 4. 手机上的文本消息 —— 构建失败了吗？
使用 SMS 发送文本消息对于紧急构建状态消息来说是一种有效的反馈形式。总的来说，我不建议一发生构建就发送文本消息（特别是还要为每条消息付费时！）。记住，太多的消息反而会增加干扰，进而会降低反馈的有效性，因而需要明智地加以选择。
X10 的优势
电子邮件很好用，当离开办公室时 SMS 也很棒，但如果想只看一眼某个东西就知道构建状态，又该如何呢？幸运的是，围绕可编程设备（称作 X10 的设备）有一整套的设施，当放到 CI 系统后这些设备能够提供一种更为被动的反馈形式。有了 X10 设备，就能够控制任何能够使用特殊硬件（可通过 X10 协议操纵）启用的电子设备。这意味着，诸如指示灯这样的日常设备就能用于通知我们构建失败。
例如，清单 3 提供了一份代码样例，用于将一个 X10 设备插入 CruiseControl 的 publisher 机制中。这个例子演示了在构建失败时，打开一盏红色的警示灯。这盏灯连接到了一个 X10 控制器上（有一些商业化的 “X10 工具包” 可用）。CruiseControl 包括 Java™ COMM API，这样就能使用 CruiseControl 的 config.xml 同该设备进行通信，将其打开或关闭。X10 控制器将连接到构建所在机器的一个通信端口上；port 属性指示使用中的通信端口。houseCode 和 deviceCode 属性指出在 X10 控制器上为该设备设置的字母及编号。onWhenBroken 属性在构建失败时指示该设备将打开（当成功构建时关闭）。interfaceModel 属性代表 X10 计算机接口。默认是 CM11A。
清单 3. CruiseControl 的 X10 配置代码
<publishers>
<x10 port="COM1" houseCode="A"
deviceCode="3" onWhenBroken="true" interfaceModel="CM17A"/>
</publishers>
|
现在，应用此机制，如图 5 中显示的设备就会在构建失败时打开：
图 5. 红色的 X10 警示灯
X10 设备种类很多（比如 LavaLamp、报警器等等），它们确实会活跃项目环境。在项目环境里将添加这些设备不仅能清晰指示构建的状态，而且也很有意思。
不要忘了监视程序和 IM
如果希望即时地接收反馈，则可以查看客户机监视程序和即时消息。客户机监视程序是一个在后台中运行的应用程序，它周期性地轮询构建服务器以获取最新的构建状态。现在几乎人人都知道什么是即时消息，如今也有许多流行平台可以实现此目的，比如 AIM、Yahoo 和 MSN。
用监视程序监视状态
CruiseControl.NET（.NET 平台的持续集成服务器）提供叫做 CCTray 的监视机制，该机制既适用于 CruiseControl.NET 也适用于传统 Java 构建 CruiseControl，且从 Windows 任务栏运行（这意味着它只能工作在 Windows 的机器上）。图 6 显示了一个实际的 CCTray 例子：
图 6. Windows 任务栏的 CCTray 监视程序
可以在非 Windows 的机器甚至在其他 CI 服务器如 Apache Continuum 上使用另一个叫作 Nag 的客户机监视程序。
用 IM 进行即时反馈
也可以使用即时消息（或 IM）将构建状态通知给项目成员。由于 IM 在开发人员间十分流行，因而它是除监视程序外的另一种快速接收反馈的方式。
CI 服务器（如 Apache Continuum ）提供一种简单的方式来发送关于构建状态的 IM。例如，图 7 显示了关于构建失败的一条消息，它使用 Jabber 将该消息从 Continuum 发送到 Google Talk 即时消息客户机。CruiseControl 也提供了一个 Jabber publisher 来发送消息。
图 7. 标志着失败构建的 IM
监视程序和 IM 是两种最为快速的发送构建状态反馈的方式，我很熟悉一些专门使用这些机制的项目团队。如果将这种方式与另一种能够让项目成员在离开办公桌时也可收到通知的方式（如电子邮件或 SMS）结合起来，则定会产生一种极为高效的反馈形式。
反馈机制的总结
正如您所见，可以在 CI 环境中采用的反馈机制有很多种。另外还有其他一些反馈机制我没有提到，比如 Ambient Orb、Web 浏览器插件、语音及小部件。表 1 提供了一份我在本文中提到过的和没有提到过的一些常见的反馈机制的总结。
表 1. 持续反馈机制
| 反馈机制 | 说明 |
|---|
| 电子邮件 | 在离散的时间点即时地提供构建状态 | | RSS | 将关于构建状态的警告推送到 RSS 阅读器 | | SMS | 将文本消息发送到手机以通知构建状态 | | X10 | 通过可视化的手段（如 Lavalamp 和红色闪光灯）提供反馈 | | Ambient Orb | 提供了另一种访问构建状态的可视化手段；能被定制用于基于具体信息的警告 | | 语音 | 通过语音发送有关构建状态的警告；对于同处一地的团队来说特别有用 | | 显示器 | 通过 LCD 显示器提供反馈 | | 小部件 | 在用户的台式机上显示构建状态；Yahoo! 和 MAC OS X 为此提供了一些小部件 ，包括 Java 的 CruiseControl Dashboard | | 监视程序 | 从 Windows 任务栏发送关于构建状态的警告 | | 即时消息 | 允许即时通知 | | 浏览器插件 | 通过浏览器通知构建状态；与 CCTray 相似，CruiseControl 的 Firefox 插件通过一个绿色或红色的图标分别表示构建成功或失败。 |
要保证能够及时采取行动的最有效方式是合理使用多个反馈机制。您可以选择最合适自己的组合。
尽情享受吧！
请记住，构建反馈的目的是为了能够迅速采取行动，这样团队才能及时修复中断的构建。通常，需要联合使用这些反馈机制才能实现此目的。例如，您可以为所有构建事件使用电子邮件的反馈方式，为构建失败（以及接下来的修复）使用 SMS 的反馈方式，为可视化通知使用一个 X10 设备。
您的团队逐渐熟悉了这些设备之后，您还可以时常加以更改，添加新的反馈机制以保持人们对构建状态的兴趣。发挥您的创造力尽情享受吧 —— 通过巧妙地添加一些反馈机制即可如此活跃气氛和激发人们对所提供信息的兴趣，这真是太棒了！
下载 | 描述 | 名字 | 大小 | 下载方法 |
|---|
| 电子邮件及 SMS 的 CruiseControl 配置文件 | j-ap11146.zip | 1800KB | HTTP |
|---|
参考资料 学习
获得产品和技术
讨论
-
提高代码质量论坛：作为在提高代码质量这方面的顾问，Andrew Glover 给这个他主持的讨论论坛带来了许多宝贵的专家经验。
关于作者
对本文的评价
| 
