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

Question

目前，我们通过一个非常简单的自制Apache接口通过FinalBuilder运行自动化（不是类似CI的东西）构建。该接口只是在我们的服务器上启动FB脚本。（我喜欢FinalBuilder，并会继续使用它，但是它的CI服务器FinalBuilder Server在我看来并不完美，特别是它目前不支持任何“代理”概念，无法将构建分布到多台机器上。）

我们在Windows上进行本地C++开发，需要时混合一些.NET。

我们当前的FinalBuilder脚本做得很好，从创建夜间版本到完整版本（构建/自动翻译/构建/单元测试/创建安装程序/将创建的产物放置在网络共享上/ ...），但我们的Web界面、排队能力、用户可追溯性和报告功能都比较有限。

我查看了一下，似乎TeamCity和Bamboo也能满足相似需求，但我找到的大多数描述仅涵盖Java和/或.NET简单构建。

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

• 几个（20-30）复杂的FinalBuilder脚本可以满足我的要求，并且我将不得不将它们集成到新的自动化/“CI”服务器中进行调用
• 本地Windows C++和.NET项目
• 目前使用几个Visual Studio解决方案文件执行实际构建（=编译器调用）
• 目前有一台构建服务器机器，希望扩展到2-3台
• 使用JIRA作为问题跟踪器
• 使用AccuRev作为SCM

哪种工具更适合，为什么：TeamCity（当前版本为6.5）或Bamboo（当前版本为3.1）。

（注意，我还希望在TeamCity和Bamboo论坛上得到一些高度主观的答案。）

- Martin Ba

Answer 1

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

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

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

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

- KIR

---

更不用说TeamCity支持预测试提交，而Bamboo目前仍然不支持。 - Engineer

Answer 2

我认为Bamboo比TeamCity更可靠。以下是我的理由：

• Jira插件对于VS或Eclipse也是Bamboo插件，不需要额外的添加。
• 更好的Jira集成支持。
• 漂亮的用户界面，与您用于Jira的界面相似。
• 能够更好地与其他Atlassian工具（如FishEye）集成。
• 价格更便宜。10美元的许可证就足够了。
• Bamboo上有更多的插件和附加组件，很多插件。

- TonySalimi

---

好的。以$10开始。TeamCity还有一个免费版本，与Atlassian产品不同，它允许远程代理。 - Martin Ba

@Martin：是的，你说得对。但是，我仍然因为其他原因坚持使用Bamboo。几周前，我为我的公司做出了同样的决定，最终选择了Bamboo。它非常棒。 - TonySalimi

Answer 3

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

- Martin Ba

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。

- Jonathan Thorpe