问题描述
|
目前，我们正在通过FinalBuilder通过一个非常简单的本地Apache界面运行自动化（不是CI本身）构建，该界面仅在服务器上启动FB脚本。 （我喜欢FinalBuilder，并且会保留它，但是它是CI服务器，FinalBuilder Server不会削减它的恕我直言-特别是它目前不支持任何“代理”概念来分发构建跨机器）。
我们正在Windows上进行本机C ++开发，并在需要和有意义的地方混合了一点.NET。
我们目前的FinalBuilder脚本可以很好地完成所有工作，从创建夜间构建到完整版本（构建/自动翻译/构建/单元测试/创建设置/将创建的工件放到网络共享中/ ...），但是我们的网络界面，排队功能，用户的可追溯性和报告非常有限。
我环顾四周，似乎TeamCity和Bamboo勾选了类似的框，但是我能找到的大多数描述仅涵盖Java和/或.NET简单构建。
所以我的具体问题是
几个（20-30个）复杂的FinalBuilder脚本，这些脚本令我满意，并且必须将其集成到新的自动化/ CI服务器中（从中调用）
本机Windows C ++和.NET项目
目前，实际的构建（=编译器调用）是通过一些Visual Studio解决方案文件完成的
目前有一台构建服务器的机器，希望扩展到2-3个atm。
使用JIRA作为问题跟踪器
使用AccuRev作为SCM
哪种工具更合适，以及为什么：TeamCity（当前为6.5）或Bamboo（当前为3.1）。
（请注意，我也希望在TeamCity和Bamboo论坛上获得一些高度主观的答案。）
解决方法
对于TeamCity而言，它与Jira集成，具有AccuRev插件，并且对VisualStudio / C ++项目具有良好的支持。它也可以运行任意脚本。
您可以通过基于HTTP的API触发构建并获取一些构建结果。在用户界面中，您可以查看已构建了哪些更改以及在哪些构建配置中。轻松将任何自定义HTML报告集成到TeamCity UI（无需编码），发布工件。
可能您应该尝试两种解决方案，然后看看哪种解决方案更适合您（使用Teamcity，您可以免费使用功能齐全的服务器，唯一的限制是构建代理的数量和构建配置的数量）。
免责声明：我是TeamCity开发人员
, 我发现Bamboo比TeamCity更可信。这是我的原因：
那些VS或Eclipse的Jira插件也是Bamboo插件。 :)不需要额外的加载项。
更好地支持Jira集成。
精美的用户界面，就像您用于Jira的界面一样。
能够更好地与其他Atlassian工具（例如FishEye）集成。
便宜点10美元的许可证足以满足您的公司要求。
与TeamCity相比，Bamboo上的附加组件更多，插件很多。
, 为了完整起见，我最终使用了Jenkins + Finalbuilder。 :-)
, 我在类似的环境中工作，使用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。