采用竹或TeamCity作为本地C++构建自动化/CI服务器？

Question

目前，我们正在通过FinalBuilder通过一个非常简单的本地Apache界面运行我们的自动化(而不是CI )构建，这个接口只是在我们的服务器上启动FB脚本。(我喜欢FinalBuilder，并会保留它，但它是CI服务器，FinalBuilder服务器只是不切断它的IMHO --尤其是目前它不支持任何“代理”概念来在机器之间分发构建。)

我们正在进行Windows上的本地C++开发，在需要的地方混合了一些.NET，这是有意义的。

我们当前的FinalBuilder脚本做的一切都很好，从创建夜间构建到完整版本(build /自动转换/构建/单元测试/创建安装/在网络共享上放置创建的工件/.)，但是我们的网络接口、排队能力、用户可跟踪性和报告都非常有限。

我环顾四周，似乎发现TeamCity和竹子之间有相似的方框，但我可以找到的大多数描述只涵盖Java和/或.NET简单的构建。

所以我的具体问题是，给了

• 几个(20-30)复杂的FinalBuilder脚本使我感到满意，并且我将不得不集成到新的自动化/“CI”服务器中。
• 本机Windows C++和.NET项目
• 实际构建(=编译器调用)目前是通过几个Visual解决方案文件完成的
• 目前有一台构建服务器机器，希望扩展到2-3台atm.
• 使用JIRA作为问题跟踪器
• 用AccuRev作为单片机

哪个工具更适合，以及为什么：TeamCity (目前为6.5)还是竹子(目前为3.1)。

(请注意，我还希望在TeamCity和竹子论坛上得到一些高度主观的答案。)

Answer 1

为了完整起见:我最终使用了詹金斯 + Finalbuilder。:-)

Answer 2

对于TeamCity端，它与Jira集成，有AccuRev插件，并且对VisualStudio/C++项目有很好的支持。它还可以运行任意脚本。

您可以通过基于HTTP的API触发构建并获得一些构建结果。在UI中，您可以看到已经生成了哪些更改以及在哪些构建配置中。轻松地将任何自定义的HTML集成到TeamCity UI中(没有编码)，发布工件。

也许，您应该尝试这两种解决方案，看看哪一种更适合您(对于Teamcity，您可以免费使用功能齐全的服务器，唯一的限制是构建代理的数量和构建配置的数量)。

免责声明:我是TeamCity开发人员

Answer 3

我发现竹子比TeamCity更可信。以下是我的理由：

• 那些用于VS或Eclipse的Jira插件也是竹插件。)不需要额外的外接程序。
• 更好地支持吉拉一体化。
• 不错的用户界面，就像你给Jira用的那个。
• 能够更好地与其他亚特兰蒂斯工具集成，如FishEye。
• 更便宜。一张10美元的执照就够你的公司了。
• 竹子上的插件比TeamCity更多，很多插件。