Thoughtworks Go vs atlassian Bamboo [关闭]答案

【问题标题】：thoughtworks go vs atlassian bamboo [closed]Thoughtworks Go vs atlassian Bamboo [关闭]
【发布时间】：2010-12-01 12:11:57
【问题描述】：

有没有人在一个和另一个上有任何 cmets。

我们正在考虑尝试自动化我们的发布过程，从开发到测试再到 uat 再到生产，包括运行单元测试、进行代码审查以及对允许谁将构建从 UAT 推送到生产中执行权限。

【问题讨论】：

go标签指的是Go编程语言。
投票只为回答它的人的水平:)

标签： release-management bamboo

【解决方案1】：

免责声明：我是 Bamboo 的产品经理

@Bernard：您能否提供更多有关您的流程的详细信息？

UAT 测试是手动测试吗？
在您的情况下，投入生产意味着什么？
您希望在部署结束时获得单一的构建结果吗？

Bamboo 2.7 是我们的第一个版本，它允许您将构建划分为不同的阶段并在阶段内并行执行作业。这可以显着改善构建的整体周转时间。我们目前正在研究工件传递，这将允许您在不同阶段之间传递构建工件。同样，这将减少整体构建时间，并且是迈向持续部署过程的又一重要步骤。

很遗憾，我们目前没有一种很好的“开箱即用”方式来对构建的某些部分强制执行权限。同样，有一些方法可以通过插件和以某种方式设置您的构建来解决这个问题。但是如果不详细了解您的流程，就很难提供建议。如果您愿意与我们分享您的流程细节，我很想亲自与您交谈（atlassian dot com 的 jens）。

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

由于 Perforce 在 Bamboo 用户中不太常用（与 CVS 和 SVN 相比），因此我们通常很少收到有关它的反馈，也很少听到有关现有问题的信息。请直接向我们提出问题，我们将尽最大努力在即将发布的版本中解决这些问题。

干杯，

延斯·舒马赫

【讨论】：

jira.atlassian.com/browse/BAM-7499 我投了赞成票。我很确定我在大约 18 个月前安装了一个类似的错误，但是这个已经足够好了。如果错误包含它无法创建的目录，至少会有所帮助，但我想如果它知道它可能只是创建它。
我还学会了如何从标签构建，我很高兴能从这个错误报告中测试它：jira.atlassian.com/browse/BAM-1684 显然文档尚未更新以反映这一点，或者我错过了它。
远离竹子！它充满了错误！他们的“部署”东西甚至不起作用......你必须手动启动它！

【解决方案2】：

我从未听说过 Go，但我可以告诉你 Bamboo 有一些严重的怪癖。根据您的源代码控制系统，您的里程可能会有所不同。

它需要一种最小公分母方法来处理它所连接的所有 SCM，因此对于使用 perforce 的我们来说，我们失去了一些我们应该免费获得的东西。

以下是一些尚未解决的烦人问题：

设置构建代理以使用特定客户端（当然，grr 必须已经存在）。现在假设客户端植根于 c:\buildarea。您必须手动创建 c:\buildarea 文件夹，否则代理会给您一些关于无法将文件提取到客户端根目录的荒谬错误。显然 'p4 sync -c YOURCLIENT' 会这样做，但 Bamboo 会做一些愚蠢的事情。

它不能做的另一件事是从现有标签正确构建。假设您有一个跨平台构建，并且您想从相同的更改列表/标签构建 linux 和 windows，在 Bamboo 中没有简单的方法可以做到这一点。您可以同时启动构建并祈祷。您可以让一个同步出另一个文件，但无法使用标签进行构建。

最后一点有点愚蠢（但并不可怕）是它假设每个人都以它“标记”构建的方式使用 CVS。当构建包含大量更改列表时，它不仅将其称为更改列表并将其编号一次，它还会列出更改列表中每个文件的“版本号”。显然，这不会破坏交易，只是对 p4 用户来说有点奇怪。

总而言之，这些问题都没有杀死我们，我们每天使用它进行数百次构建，并且在任何给定时间都有大约 200 个构建计划处于活动状态。我确信我可以想到其他问题，但很多事情都已经解决了。

【讨论】：

我确实记得另一个主要问题。这就是我们不对 Bamboo 帐户使用公司范围的 LDAP 的原因：jira.atlassian.com/browse/BAM-1199 显而易见的解决方案是从一开始就使用 LDAP，因为您可能会发现将来迁移到它会很头疼。

【解决方案3】：

@Bernard：我在 ThoughtWorks 工作，使用 Go (Cruise) 的经验比使用 Bamboo 的经验多，所以我现在就为您提供有关 Go 解决您的问题的信息

“我们正在考虑尝试自动化我们的发布过程，从开发到测试再到 uat 到生产”：通过部署管道对整个发布过程进行建模和自动化已经被 Go 概念化并且已经存在自其早期版本（以前称为 Cruise）以来。部署管道将复杂的构建分解为一系列阶段，这些阶段本身就是作业的集合。这些阶段可以手动或自动触发。当更改从管道仪表板 UI 本身通过环境传播时，查看和控制更改流也非常容易。这是自动部署到 UAT 的详细示例 (http://www.thoughtworks-studios.com/go/2.0/help/rm_deploy_to_environment.html)。
“包括运行单元测试，进行代码审查”： Go 使您能够拆分测试套件并并行运行它们。您还将获得一份全面的报告，其中包含有关哪些作业失败、失败的测试、哪些签入破坏了测试等的详细跟踪，以及您选择的构建事件的电子邮件警报。 Go 还自动发布工件，这些可以从报告本身中查看。这在嗅探构建时非常有用。在 Go 中，实现棘轮非常简单 (http://skizz.biz/blog/2008/03/11/fixing-broken-windows-with-ratcheting/)，因此您可以使不符合您的编码的构建失败标准阈值。
“并强制允许谁将构建从 UAT 推送到生产环境”：您可以通过对管道进行分组来控制对具有查看和操作权限的项目和环境的访问。此外，您可以锁定允许触发构建的人员。

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

@jgritty： Go is the successor to Cruise 来自 ThoughtWorks Studios。

【讨论】：

【解决方案4】：

我使用过 Bamboo/TeamCity/Jenkins/etc 并最近针对标准 CI 服务器审查了 ThoughWorks Go。

我真的很想看看他们是否解决了团队管理和发布问题。我个人最喜欢 TeamCity，但给了 Go 一个机会。老实说，我有点失望，作为一个纯粹的构建服务器，它没有 TeamCity/Bamboo 先进。它缺乏对关键 SCM 和构建工具的支持。此外，大多数构建服务器都对 FindBugs/PMD/Emma/Clover/etc 等 3rd 方工具有很多支持，Go 不支持

与市场上其他产品不同的一个方面是环境的概念以及在不同环境中移动的能力。然而，这是该概念的一个非常原始的版本。

Thoughtworks 的人是世界上最优秀的人之一，并且在开发团队方面拥有丰富的经验，我希望看到更多该工具的发布，他们真正开始解决围绕软件开发过程的一些关键问题

我的快速回顾可以在这里找到

http://diarmuidmoloney.wordpress.com/2011/11/24/thoughtworks-go/

【讨论】：