ThoughtWorks Go与Atlassian Bamboo比较

7

有没有人对其中一个有任何评论?

我们正在尝试将我们的发布流程从开发自动化到测试,再到用户验收测试,最后到生产环境。这包括运行单元测试,进行代码审查以及强制执行谁有权限将构建从用户验收测试推送到生产环境。


go标签指的是Go编程语言。 - peterSO
1
只为那些回答问题水平高的人点赞 :) - Spedge
4个回答

4

声明:我是Bamboo的产品经理

@Bernard: 你能提供一些有关你的流程的详细信息吗?

  • UAT测试是手动测试吗?
  • 在你的情况下,推入生产意味着什么?
  • 你是否期望在部署结束时获得单个构建结果?

Bamboo 2.7是我们的第一个发布版,它允许您将构建分成不同的阶段,并在阶段内并行执行作业。这可以显着提高构建的总体周转时间。我们目前正在开发传递构建工件的功能,这将允许您在不同阶段之间传递构建工件。同样,这将减少总体构建时间,并是实现持续部署流程的又一重要步骤。

不幸的是,我们目前没有一个很好的“开箱即用”的方法来强制执行对构建某些部分的权限。同样,在不了解您的流程的更多细节的情况下,很难提供建议。如果您愿意与我们分享流程的详细信息,我很乐意与您当面交谈(jens at atlassian dot com)。

@jgritty: 你指出的问题部分是我们Perforce集成的已知问题,部分似乎是未知的错误。请随时在support.@atlassian.com上创建支持请求或在jira.atlassian.com上提出错误报告。

由于相对于CVS和SVN,Bamboo用户中使用Perforce的比例较少,因此我们通常会收到更少的有关其问题的反馈。请直接向我们报告问题,我们将尽力在即将推出的版本中修复它们。

干杯,

Jens Schumacher


http://jira.atlassian.com/browse/BAM-7499 我投了赞成票。我很确定大约18个月前我提交过一个类似的错误报告,但这个已经足够好了。至少如果错误信息包含无法创建的目录,那将会很有帮助,但我想如果它知道那个目录,它可能只是直接创建它。 - jgritty
我也学会了如何从标签构建,并且很兴奋能够通过这个错误报告进行测试:http://jira.atlassian.com/browse/BAM-1684。 显然文档还没有更新以反映这一点,或者我错过了它。 - jgritty
远离Bamboo!它充满了漏洞!他们的“部署”功能甚至都不起作用...你必须手动启动它! - themihai

3
我从未听说过Go语言,但我可以告诉你Bamboo有一些严重的缺陷。根据您的源代码控制系统,您的使用情况可能会有所不同。它采用了一种最常见的方法来处理所有SCMs的钩子,因此对于我们使用Perforce的用户而言,我们失去了一些应该免费获得的功能。
以下是一些令人烦恼的问题,至今仍未解决:
1. 设置一个构建代理以使用特定客户端(当然必须已经存在),例如,假设客户端的根目录为c:\buildarea。您必须手动创建c:\buildarea文件夹,否则代理将给您一些荒谬的错误,指出无法将文件提取到客户端根目录。显然,“p4 sync -c YOURCLIENT”可以完成这项任务,但Bamboo却做了一些愚蠢的事情。
2. 另一件它无法做到的事情是从现有标签中正确构建。假设您有一个跨平台构建,想要同时从完全相同的变更列表/标签构建Linux和Windows,则在Bamboo中没有简单的方法进行操作。您可以同时启动构建并祈祷。您可以让其中一个同步另一个的文件,但没有使用标签进行构建的方法。
3. 最后一个有点愚蠢(但不是很糟糕)的问题是,它有点假设每个人都使用CVS来“标记”构建。当一个构建包含大量变更列表时,而不仅仅是称其为变更列表并对其进行编号,它会列出每个变更列表中每个文件的“版本号”。显然,这不是致命问题,只是对于Perforce用户来说有点奇怪。
总的来说,这些问题没有毁掉我们,我们每天进行数百次构建,并且在任何给定时间都有大约200个构建计划处于活动状态。我相信我可以想到其他问题,但许多问题已得到解决。

我记得还有一个主要问题。这就是我们不使用公司范围内的LDAP作为Bamboo帐户的原因:http://jira.atlassian.com/browse/BAM-1199 明显的解决方案是从一开始就使用LDAP,因为你可能会发现将来迁移到它会带来很大的麻烦。 - jgritty

3
@Bernard: 我在 ThoughtWorks 工作,使用 Go(之前称为 Cruise)的经验比 Bamboo 更多,所以我将为您提供有关 Go 如何解决您的问题的信息。
  1. "我们希望尝试自动化从开发到测试再到 UAT 再到生产的发布流程": 通过部署流水线对整个发布过程进行建模和自动化已被 Go 概念化,并且自早期版本(之前称为 Cruise)就存在了。部署流水线将复杂的构建拆分为一系列阶段,每个阶段本身都是一组作业。可以手动或自动触发这些阶段。通过管道仪表板 UI,非常容易查看和控制更改在环境中传播的流程。以下是自动部署到 UAT 的详细示例(http://www.thoughtworks-studios.com/go/2.0/help/rm_deploy_to_environment.html)。
  2. "包括运行单元测试、进行代码审查": Go 可以让您拆分测试套件并并行运行它们。您还会得到一个全面的报告,其中详细记录了哪些作业失败、哪些测试失败、哪个提交破坏了测试等内容,以及您选择的构建事件的电子邮件警报。Go 还会自动发布构件,并且可以从报告本身查看这些构件。在查找构建问题时,这非常有用。在 Go 中,实现固定阈值(http://skizz.biz/blog/2008/03/11/fixing-broken-windows-with-ratcheting/)非常简单,因此您可以使不符合编码标准阈值的构建失败。
  3. "并对允许从 UAT 推送构建到生产的人员强制执行权限": 您可以通过分组管道来控制对项目和环境的查看和操作权限。此外,您可以限制谁有权触发构建。

与市场上许多工具不同,Go 提供了触发构建之间的关系、环境建模、并行构建结果的聚合、自动发布构件以及自动更新构建代理的可见性。

@jgritty: Go 是 ThoughtWorks Studios 的 Cruise 的继任者


2
我之前使用过Bamboo/TeamCity/Jenkins等标准CI服务器,最近又评估了ThoughtWorks Go。我真的很想知道他们是否解决了团队管理和发布问题。我个人最喜欢TeamCity,但也试用了Go。老实说,作为纯构建服务器,它远不如TeamCity/Bamboo先进。它缺乏对关键源代码管理(SCM)和构建工具的支持。此外,大多数构建服务器有很多对第三方工具的支持,例如FindBugs/PMD/Emma/Clover等,而Go却没有。
市场上唯一与其他产品不同的领域是环境的概念以及通过不同环境进行移动的能力。然而,这个概念的版本非常原始。
Thoughtworks的团队是世界上最好的,拥有丰富的开发团队经验,我期望看到更多的该工具版本发布,他们会真正开始解决软件开发过程中的一些关键问题。
我的快速评估可以在这里找到:http://diarmuidmoloney.wordpress.com/2011/11/24/thoughtworks-go/

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接