设置集成测试服务器的最佳方式是什么？
你一定要分手任务。这是CruiseControl.NET配置的一个很好的例子，每个步骤都有不同的目标（任务）。它还使用了一个common.build文件，可以在少量定制的项目之间共享。
http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk
我使用TeamCity和nant构建脚本。 TeamCity可以很容易地设置CI服务器部分，而且nant构建脚本使得就报告生成而言，可以轻松完成许多任务。
这里是一个文章，我写了关于使用CI与CruiseControl.NET，它在评论南特构建脚本跨项目，可重复使用：
我肯定会打破工作。很可能你会在构建中进行更改，如果你有更小的任务，而不是通过单一构建进行搜索，那么跟踪问题会更容易。
无论如何，您应该可以从小块创建一个大工作。
天儿真好，
当你在谈论集成测试我的大（明显）的小费是使测试服务器构建和配置，尽可能接近到部署环境可能。
</thebloodyobvious> (-:
欢呼声， 罗布
的做法我赞成如下设置（实际上假设你是一个.NET项目）：
- CruiseControl.NET。
- 每个单独步骤的NANT任务。 Nant.Contrib替代CC模板。
- NUnit运行单元测试。
- NCover执行代码覆盖。
- FXCop用于静态分析报告。
- Subversion for source control。
- CCTray或类似的所有dev的箱子得到的通知建立和失败等
在你发现有不同程度的测试和活动需要，当有人不签入的地方很多项目。有时候，这些可能会增加到一定程度，以至于在开发之前可能需要很长时间才能看到他们是否用签入破坏了构建。
我在这些情况下，做的是创建三个建立（或者两个）：
- 一个CI构建被签入触发和不干净的SVN获取，构建和运行轻量级测试。理想情况下，您可以将其降低到几分钟或更少。
- 一个更全面的构建，可以每小时（如果更改）与CI完全相同，但运行更全面和更耗时的测试。
- 过夜的构建，其做的一切，并运行的代码覆盖率和组件的静态分析和运行任何部署步骤来建立日常MSI软件包等
任何CI系统中最关键的是，它需要有机并不断调整。 CruiseControl.NET有一些非常好的扩展功能，可以为步骤记录日志和图表构建时间等，并让您进行历史分析，并让您不断调整构建以保持活跃。这是管理人员很难接受的一种情况，即构建箱可能会让你忙于工作时间的五分之一，以阻止它停滞不前。
我们使用buildbot，构建分解为不连续的步骤。在将构建步骤细分为足够的粒度和完整的单元之间有一个平衡点。例如，在我现在的位置，我们在各自的平台上为我们的每个平台（Mac，Linux，Windows）构建子部分。然后，我们只需一个步骤（有几个子步骤）将它们编译成最终版本，最终版本将以最终版本为准。
如果在这些步骤中有任何问题出现，那么诊断非常容易。
我的建议是尽可能以模糊的术语在白板上写出步骤，然后根据这些步骤制定步骤。在我而言，这将是：
- 生成插件饮片
- 编译为Mac
- 编译PC
- 编译的Linux
- 做最后的插件
- 运行插件测试
- 构建中间IDE（我们要引导建筑）
- 构建最终IDE
- 运行IDE测试
向上突破你的任务分解成离散的目标/行动，然后用更高级别的脚本一起适当配合他们。
这使得您的构建过程更易于其他人理解（您正在记录，因此您的团队中的任何人都可以拿起它，对吗？），以及增加重复使用的可能性。很可能你不会重用高级脚本（尽管如果你有类似的项目，这可能是可能的），但你可以很容易地重用（即使是复制/粘贴）离散操作。
考虑从存储库获取最新源代码的示例。您需要将用于检索代码的任务/操作与一些日志记录语句进行分组，并引用相应的帐户信息。这是从一个项目到下一个项目非常容易重用的事物。
对于我的团队环境，我们使用NAnt，因为它在开发机器（我们编写/调试脚本的地方）和CI服务器（因为我们只是在干净的环境中执行相同的脚本）之间提供了一个通用的脚本环境。我们使用Jenkins来管理我们的构建，但是在他们的核心中，每个项目只是调用相同的NAnt脚本，然后我们操纵结果（即存档构建输出，标记失败的测试等）。