设置集成测试服务器的最佳方法是什么？答案

【问题标题】：What is the best way to setup an integration testing server?设置集成测试服务器的最佳方法是什么？
【发布时间】：2008-08-27 12:20:48
【问题描述】：

设置集成服务器时，我对使用多个任务完成构建的最佳方法表示怀疑。最好的方式是只做一项大工作还是做一些小的依赖？

【问题讨论】：

标签： continuous-integration integration-testing

【解决方案1】：

你肯定想分解任务。这是 CruiseControl.NET 配置的一个很好的示例，每个步骤都有不同的目标（任务）。它还使用了一个 common.build 文件，该文件可以在几乎不需要自定义的项目之间共享。

http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk

【讨论】：

【解决方案2】：

我将 TeamCity 与 nant 构建脚本一起使用。 TeamCity 可以轻松设置 CI 服务器部分，而 nant 构建脚本可以轻松完成报告生成方面的许多任务。

这是我写的一篇关于在 CruiseControl.NET 中使用 CI 的文章，它在 cmets 中有一个可以跨项目重复使用的 nant 构建脚本：

Continuous Integration with CruiseControl

【讨论】：

【解决方案3】：

我喜欢的方法是以下设置（实际上假设您在一个 .NET 项目中）：

CruiseControl.NET.
每个单独步骤的 NANT 任务。 Nant.Contrib 用于替代 CC 模板。
NUnit 运行单元测试。
NCover 执行代码覆盖。
FXCop 用于静态分析报告。
Subversion 用于源代码控制。
所有开发盒上的 CCTray 或类似设备，以获取构建和故障等通知。

在许多项目中，您会发现当有人签到时会进行不同级别的测试和活动。有时，这些可能会随着时间的推移而增加，以至于在构建之后很长一段时间，开发人员才能看到他们是否通过签入破坏了构建。

在这些情况下我所做的是创建三个构建（或者可能两个）：

CI 构建由签入触发，并执行干净的 SVN 获取、构建和运行轻量级测试。理想情况下，您可以将其控制在几分钟或更短的时间内。
一个更全面的构建，可以每小时（如果发生变化）与 CI 相同，但运行更全面和耗时的测试。
一夜之间构建，它可以完成所有工作，还运行代码覆盖率和程序集的静态分析，并运行任何部署步骤来构建日常 MSI 包等。

任何 CI 系统的关键在于它必须是有机的，并且需要不断地进行调整。 CruiseControl.NET 有一些很棒的扩展，它们记录和图表构建时间等步骤，并让您进行历史分析，因此允许您不断调整构建以保持它们的敏捷性。经理们很难接受一个构建框可能会让您忙于工作时间的五分之一，只是为了阻止它停止运行。

【讨论】：

【解决方案4】：

我们使用buildbot，将构建分解为离散的步骤。在以足够的粒度分解构建步骤和成为一个完整的单元之间找到平衡。

例如，在我目前的职位上，我们在各自的平台上为每个平台（Mac、Linux、Windows）构建子部分。然后，我们有一个步骤（包含几个子步骤）将它们编译成最终版本，最终将出现在最终发行版中。

如果这些步骤中的任何一个出现问题，很容易诊断出来。

我的建议是尽可能用模糊的术语在白板上写下这些步骤，然后以此为基础。就我而言，这将是：

构建插件片段
1. 为 Mac 编译
2. 为 PC 编译
3. 为 Linux 编译
制作最终插件
运行插件测试
构建中间 IDE（我们必须引导构建）
构建最终的 IDE
运行 IDE 测试

【讨论】：

【解决方案5】：

我肯定会分解工作。您可能会在构建中进行更改，如果您有较小的任务而不是搜索一个单一的构建，那么跟踪问题会更容易。

无论如何，您应该能够从较小的部分创建一个大工作。

【讨论】：

【解决方案6】：

生日，

当您谈论集成测试时，我的大（显而易见）提示是使测试服务器的构建和配置尽可能接近部署环境。

</thebloodyobvious> (-:

干杯，抢

【讨论】：

【解决方案7】：

将您的任务分解为离散的目标/操作，然后使用更高级别的脚本将它们适当地结合在一起。

这使其他人更容易理解您的构建过程（您在进行过程中进行记录，以便团队中的任何人都可以了解它，对吗？），并增加了重用的可能性。您可能不会重用高级脚本（尽管如果您有类似的项目，这可能是可能的），但您绝对可以相当轻松地重用（即使是复制/粘贴）离散操作。

考虑从您的存储库获取最新源的示例。您需要将用于检索代码的任务/操作与一些日志记录语句进行分组，并参考适当的帐户信息。这是一种很容易从一个项目重用到下一个项目的东西。

对于我团队的环境，我们使用 NAnt，因为它在开发机器（我们编写/调试脚本的地方）和 CI 服务器（因为我们只是在干净的环境中执行相同的脚本）之间提供了一个通用的脚本环境。我们使用 Jenkins 来管理我们的构建，但每个项目的核心只是调用相同的 NAnt 脚本，然后我们操纵结果（即归档构建输出、标记失败的测试等）。

【讨论】：