持续集成工具的经验

Question

我们正在尝试设置持续集成。我们的软件套件包含大约20个C＃解决方案。对于某些项目，单元测试（NUnit）已经可用。我们希望自动化构建和测试过程，并尽早获得有关更改的信息。

最近，我试图与哈德森合作。通过网络进行密集搜索后可以解决一些问题，并进行一些反复试验。

现在，一个错误阻止我们取得成功：当然，我们的解决方案共享一些组件。当共享组件发生更改时，我们不希望构建过程在第一次失败后停止 - 我们想知道所有被破坏的项目。当使用＆＃34;参数化触发器插件版本2.4＆＃34;时，Hudson也无法处理这个问题。 （它完成了第一次完成后启动下一个项目，并在构建失败后失败。然后，甚至没有发送电子邮件通知，之后，根本没有下游项目启动 - 即使是成功的上游项目！）。

由于目前Hudson的经历非常令人失望，我们考虑采用不同的系统。

您能否从积极的经验中推荐一个持续集成工具：

• 与Subversion集成（用于获取源代码和触发构建）
• 启动msbuild（例如Windows命令行）
• 触发更多项目，无论上游项目中的失败（必须这样做！）
• 构建失败时通过电子邮件通知
• 使用NUnit（例如命令行）启动单元测试
• 单元测试失败时通过电子邮件通知
• 与构建/测试环境中的其他计算机合作，在其他系统上部署/测试
• 提供社区支持

更新： 我试过詹金斯。无论上游项目中的故障如何，它都会触发进一步构建。 Haven尚未对最后两点进行测试。

Answer 1

[免责声明：为CI工具制造商工作的人员的回复]

Bernhard，你的要求（特别是管理解决方案间的依赖性）非常适合我公司的AnthillPro。

• 与Subversion集成（用于获取源代码和for 触发构建）
  • 是的。我们使用轮询或SVN提交后触发器来检测源代码更改并立即触发构建。
• 启动msbuild（例如Windows命令行）
  • 我们有一个开箱即用的MS Build构建类型。

• 触发更多项目，无论上游项目是否失败 （必须这样做！）

  • AnthillPro中的触发非常棒。它可以处理大型构建图，并行构建任何相关组件，而不进行不必要的构建。自从我们在2001年首次引入触发以来，我们一直在改进这种能力。

• 构建失败时通过电子邮件通知

  • 电子邮件和/或实例消息。

• 使用NUnit（例如命令行）启动单元测试

  • 支持NUnit测试结果解析。

• 单元测试失败时通过电子邮件通知

  • 与构建失败的通知类似

• 与构建/测试环境中的其他计算机合作 在其他系统上部署/测试

  • 完全支持通过环境部署构建。环境是AnthillPro中的第一个概念。

• 提供社区支持

  • 这是可能的问题。我们的产品不是免费的。这是镀金的CI / CD工具。