由于有许多持续集成服务（CI）服务器可以选择，所以很难决定哪个适应自己。在 让开发自动化 系列的第二篇文章中，开发自动化专家 Duvall 采用一致的评估标准和很多说明性示例，介绍了一些开源 CI 服务器，包括 Continuum、CruiseControl 和 Luntbuild。
在我脑海里，我至少能想到 12 种在当前市场上可用的 CI 服务器，包括商业的和开源的。虽然它们都试图自动进行软件构建的过程，但是都有各自的优点和不足。而且，有太多工具可供选择的不良后果就是很难决定究竟应该选择使用哪个。
在选用自动化过程的工具时，要时刻记住的就是：工具要 确实适用。选择错误的工具可能会限制整体的灵活性，会导致执行简单动作反而需要更长时间，或者会把人锁定在特定的支持工具或过程。
通常，对一个新工具的决策分析可以归结如下：
我听说 Tim 在使用 Acme Inc 的工具，而且我认为 Tim 是个聪明人。所以，我也要使用 Acme Inc 的工具。现在我也是个聪明人了。
 |
反过来，如果您问 Tim 为什么 他选择使用 Acme Inc 的工具，您可能会发现是他的公司强制要求使用的。这就是为什么重要的是要根据 自己的 具体技术和政策需求对工具进行分析。如果不这么做，可能就会选择到不符合需求的工具，甚至更糟糕的是，不能带来任何帮助的工具。
在决策的时候，通常多数人都会把重点放在工具的特性上。但是要记住，虽然特性的确重要，但还有其他指标需要考虑。在我的实践中，我发现以下五个指标在评估工具时最有帮助：
|
|
- 特性
- 可靠性
- 寿命
- 目标环境
- 易用性
而且不要忘记，客观地 检查这五个方面也是重要的。
说到 CI 服务器的特性，应当考虑该工具与版本控制系统的集成、处理构建平台（例如 Ant 和 Maven）的能力以及提供反馈和报告的能力。而且不要忘记检查其他特性，例如构建标号和管理项目的依赖项。最后，在需要做一些特定的增强时，理解产品的可扩展性会很有帮助。
表 1 详细说明了每个特性：
CC>表 1. 详细的 CI 服务器评估特性
| 特性 | 解释 |
|---|---|
| 版本控制系统集成 | 如果工具不支持您所使用的特定版本控制系统，您真的会为它编写一个定制集成么？ |
| 构建工具集成 | 在选择 CI 服务器时，需要考虑目前或将要使用哪个构建工具。对于 Java™ 编程，有两个自然的选择：Ant 和 Maven，几乎所有 CI 工具都支持它们。如果构建系统既不是 Ant 也不是 Maven，那么 CI 工具支持从命令行运行程序的功能么？ |
| 反馈和报告 | 想想老话 “如果树倒在森林中，能有人听到么？” 如果构建失败，会有人知道么？如果没人知道，那么使用 CI 工具的目的是什么？所有的 CI 工具都提供一些通知机制，但是哪个最适合您呢？电子邮件？即时消息？RSS？ |
| 标号 | 有些开发团队喜欢跟踪构建，给构建一个唯一的标号，这样日后就能找到具体的构建实例。如果这对您来说很重要，那么要注意只有少数 CI 服务器提供了这个功能。 |
| 项目依赖项 | 某些情况下，在构建了一个项目之后，可能需要构建其他依赖项目。有些 CI 服务器支持这个特性，有些不支持。 |
| 易于扩展 | 扩展工具当前的功能有多容易？是否用插件就可以实现简单的扩展，还是总得修改代码？ |
从特性的角度来说，以上提到的几点在选择所需要的正确的 CI 服务器时，至关重要。
因为下载和使用开源 CI 服务器很简单，所以可以试用产品来判断它的可靠性。而且，在工具的可靠性和它在市场上的时间之间，通常存在一些相关性。使用新产品时，就会冒着有未发现的 bug 的风险。而且，用户群是发现工具出现的问题的优秀资源。大量的问题贴子或者过多的复杂问题，就表示用户对这个工具的意见较大。
因为我这里讨论的服务器是开源的，所以很容易发现下载的人数，这也会是产品健康程度的一个指示。用户少可能意味着反馈渠道少，可能需要换个地方看看。
在下载 CI 服务器之前，了解这个服务器未来的前景会有帮助。简单地说，使用已经死亡或正走向死亡的产品不是个好主意。可以检查该工具已经出现了多少年、在它的用户群中是否有正常数量的活动。就像可以从用户群来判断产品的可靠性一样，活跃的社区是工具未来前景良好的征兆。
CI 服务器不能在 所有 环境下工作。需要考虑服务器支持哪个操作系统以及具体的系统需求。例如，如果工具是用最新版本的 Python 编写的，那么需要确定这个版本 Python 能够用于自己的操作系统。
产品的易用性可能是最主观的指标。有些人愿意手工修改配置文件，而有些人想让所有管理任务都在应用程序中执行，例如 Web 控制台。有些服务器要求从一个屏幕单击到下一个屏幕来执行简单的管理，而其他服务器则提供了直观的向导。
如果想理解 CI 服务器的具体细节，那么漂亮的管理 Web 表单就不重要了；但是，如果人手不足、工作繁忙，那么可能不会想在管理 CI 服务器上花太多时间。
记住我在这节讨论的五个方面，再来看一下三个 CI 服务器：Apache 的 Continuum、CruiseControl 和构建管理服务器 Luntbuild。
Continuum 是最新的 CI 服务器之一，也是值得关注的一个新进入者。Continuum 的安装和配置很简单：只要下载和释放 ZIP 文件，运行命令行程序，就可以运行了。基于 Web 的界面使得配置项目很容易。而且，还不需要安装 Web 服务器，因为 Continuum 内置了 Jetty Web 服务器。并且，Continuum 可以作为 Windows 服务运行，还在应用程序的某些部分嵌入了上下文敏感的文档，从而提供了很多帮助。
|
|
在使用 Continuum 时会注意到的第一件事就是它的易用性。能够在几分钟之内就把服务器运行起来并让它去查询修改。实际上，在 Windows 上启用 Continuum 只需要四步：
- 下载 Continuum ZIP 文件（请参阅 参考资料）。
- 把文件的内容释放到本地目录。
- 运行 run.bat 文件，然后运行 InstallService.bat。
- 打开浏览器指向 http://localhost:8080/。
Continuum 内置支持五个版本控制系统：Subversion、CVS、StarTeam、Bazaar 和 Perforce。也部分地支持其他版本控制工具，例如 Visual Source Safe 和 ClearCase。 Continuum 还支持四种构建机制：Ant、Maven1、Maven2 和 Shell（命令行）。
在第一次访问 Continuum Web 应用程序时，默认是 guest 帐户。guest 提供了对所有项目的只读存取，没有管理或配置项目的能力。但是，可以很容易地创建 Administrative 用户，然后设置一些适用于所有项目的属性。
图 1 显示了管理页面，它提供了管理所有项目的 Continuum 设置的能力，包括创建 Admin 帐户、构建的输出和部署目录：
图 1. Continuum 的配置很简单
对 Continuum 进行配置让它监视项目也非常简单。简单到仅仅是选择期望的构建平台，例如 Ant 或 Maven2，然后把 Continuum 指到期望的版本控制系统。
图 2 显示了设置 Ant 项目时需要填充的字段：
图 2. 在 Continuum 中创建项目
在保存了这个信息之后，Continuum 每小时查询版本控制系统一次。可以修改项目的设置，查询得更频繁或更少些。我们在这里谈到的是 持续 集成，我建议每五 分钟检查修改一次，而不要每小时一次。
默认情况下，在使用 Ant 时，Continuum 在项目的根目录查找项目的 build.xml 文件。如果使用不同的名称或者这个文件不在项目的根目录，可以修改这个设置。
虽然 Continuum 还是 CI 舞台上的新人，但是它以其易用性和对当前众多流行的版本控制系统和构建工具的支持，还是给这一领域带来了巨大的冲击。我希望在未来的版本中会有添加和查看报告的功能。
文章来源于领测软件测试网 https://www.ltesting.net/
