采用 Bamboo 或 TeamCity 作为原生 Windows C++ 构建自动化/CI 服务器？

Question

目前，我们正在通过FinalBuilder 运行我们的自动化（不是 CI）构建，通过一个非常简单的本土 Apache 界面，该界面仅在我们的服务器上启动 FB 脚本。 （我喜欢 FinalBuilder，并且会保留它，但它是 CI 服务器，FinalBuilder Server 恕我直言 - 特别是它目前不支持任何“代理”概念来跨机器分发构建。）

我们正在 Windows 上进行原生 C++ 开发，并在需要且有意义的地方混合了一点 .NET。

我们当前的 FinalBuilder 脚本做得很好，从创建夜间构建到完整版本（构建/自动翻译/构建/单元测试/创建设置/将创建的工件放在网络共享上/...），但我们的 webinterface、排队能力、用户可追溯性和报告非常有限。

我环顾四周，似乎 TeamCity 和 Bamboo 勾选了类似的框，但我能找到的大多数描述仅涵盖 Java 和/或 .NET 简单构建。

所以我的具体问题是，鉴于

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

哪个工具更适合，为什么：TeamCity (currently 6.5) 或Bamboo (currently 3.1)。

（请注意，我也希望在TeamCity 和Bamboo 论坛上得到一些非常主观的答案。）

Answer 1

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

您可以通过基于 HTTP 的 API 触发构建并获取一些构建结果。在 UI 中，您可以查看已构建哪些更改以及哪些构建配置。轻松将任何自定义 HTML 报告集成到 TeamCity UI（无需编码），发布工件。

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

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

Answer 2

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

• 那些用于 VS 或 Eclipse 的 Jira 插件也是 Bamboo 插件。 :) 不需要额外的插件。
• 更好地支持 Jira 集成。
• 不错的用户界面，就像您用于 Jira 的界面一样。
• 能够更好地与其他 Atlassian 工具集成，例如 FishEye。
• 更便宜。 10 美元的许可证足以满足您的公司。
• Bamboo 上的附加组件比 TeamCity 多，还有很多插件。

Answer 3

为了完整起见：我最终使用了Jenkins + Finalbuilder。 :-)

Answer 4

我在类似的环境中工作，使用 FinalBuilder 进行构建自动化、AccuRev 进行源代码控制和原生 Windows 项目。

我最终选择 Electric Commander 作为这项工作的最佳 CI 解决方案。可以重用部分 FinalBuilder 脚本并从 Electric Commander 调用它们，但仅将 FB 脚本作为一个构建步骤调用会导致您错过使用 Electric Commander 的一些关键优势 - 实时日志文件处理、在 Electric Commander 以及数据收集和报告中并行化到各个步骤级别。

Electric Commander 的 API 公开了所有产品功能，可与 AccuRev 触发器结合使用以实现非常灵活的解决方案。

免责声明 - 我非常喜欢 Electric Commander，因此我加入了该公司，目前受雇于 Electric Cloud。

您可以前往www.electric-cloud.com 并点击“试试看！”来试用 Electric Commander！