设置集成服务器时，我怀疑使用多个任务完成构建的最佳方法。是将所有工作全部放在一个大工作中或者让一个小受抚养人的最好方法吗？

解决方案

回答

我将TeamCity与nant构建脚本一起使用。 TeamCity使设置CI服务器部分变得容易，而nant构建脚本使就报告生成而言轻松完成许多任务。

这是我写的关于将CI与CruiseControl.NET一起使用的文章，该文章的注释中包含一个nant构建脚本，可以在项目中重复使用该脚本：

与CruiseControl的持续集成

回答

我一定会分解工作。我们可能会在构建中进行更改，并且如果任务较小，而不是搜索一个整体的构建，则更容易查找问题。

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

回答

我们肯定想分手任务。这是CruiseControl.NET配置的一个很好的示例，该配置的每个步骤都有不同的目标(任务)。它还使用common.build文件，几乎无需定制即可在项目之间共享。

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

回答

G'day，

当我们谈论集成测试时，我的(显而易见的)秘诀是使测试服务器的构建和配置尽可能地接近部署环境。

</thebloodyobvious> (-:

干杯，
抢

回答

我喜欢的方法是以下设置(实际上假设我们在.NET项目中)：

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

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

在这些情况下，我要做的是创建三个构建(或者两个)：

• CI构建由签入触发，并执行干净的SVN获取，构建和运行轻量级测试。理想情况下，我们可以将其减少到几分钟或者更短。
• 可能会每小时(如果有更改)的更全面的构建与CI相同，但运行更全面且耗时的测试。
• 一夜之间可以完成所有工作的构建，还可以对程序集进行代码覆盖和静态分析，并运行任何部署步骤来构建每日MSI程序包等。

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

回答

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

例如，在我目前的位置上，我们在各自的平台上为我们的每个平台(Mac，Linux，Windows)构建子组件。然后，我们有一个步骤(包括几个子步骤)将它们编译为最终版本，最终将最终发布。

如果这些步骤中的任何步骤出了问题，则很容易诊断。

我的建议是尽可能用模糊的措辞在白板上写出步骤，然后在此基础上进行操作。以我为例：

• 为PC编译
• 为Linux编译
• 制作最终插件
• 运行插件测试
• 构建中间IDE(我们必须自举构建)
• 构建最终的IDE
• 运行IDE测试