使用连续集成工具的经验

Question

我们正在尝试建立持续的集成。我们的软件套件由大约20种C#解决方案组成。对于某些项目，单元测试(NUnit)已经可用。我们希望将构建和测试过程自动化，并尽早获取有关中断更改的信息。

最近，我试着和哈德逊一起这么做。通过网络进行密集搜索，可以解决一些问题，也有一些尝试和错误。

现在，一个bug阻止了我们前进:当然，我们的解决方案共享一些组件。当一个共享组件被更改时，我们不希望构建过程在第一次失败之后停止--我们想知道所有被破坏的项目。这是Hudson无法处理的，在使用“参数化触发器插件2.4”时也是如此(它处理的是在第一个完全完成后启动下一个项目，在构建失败后失败)。然后，甚至没有发送电子邮件通知，然后，没有启动下游项目-即使在成功的上游项目！)。

到目前为止，哈德逊的经历非常令人失望，我们想要采取一种不同的制度。

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

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

更新:我试过詹金斯了。无论上游项目是否失败，它都会触发进一步的构建。还没有测试过去的两分。

Answer 1

免责声明:为CI工具制造商工作的人的回应

Bernhard，您的需求(特别是管理解决方案间依赖项)非常适合我公司的AnthillPro。

• 与Subversion集成(用于获取源代码和触发构建)
  • 是啊。我们使用轮询或SVN后提交触发器来检测源代码更改，并立即触发构建。

​

• 启动msbuild (例如Windows命令行)
  • 我们有一个类型的开箱即用。

​

• 触发进一步的项目，无论上游项目失败(必须做！)

- The triggering in AnthillPro is awesome. It can handle large build graphs, building any dependent components in parallel while not doing unnecessary builds. We've been improving this capability since we first introduced triggering in 2001. 

​

• 生成失败时通过电子邮件通知

- Email and/or instance message.  

​

• 使用NUnit启动单元测试(例如命令行)

- NUnit test result parsing is supported.

​

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

- Similar to notification of build failure

​

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

- Fully supports deployments of builds through environments. Environments are a first oder concept within AnthillPro. 

​

• 提供社区支持

- Here's the possible issue. Our product isn't free. It's the gold-plated CI/CD tool.

​