Thoughtworks Go 开源

Photo of Martin Fowler

马丁·福勒是一位软件开发领域的作家、演讲者和“大嘴巴”。他是 Thoughtworks 的 首席科学家

2014 年 3 月 25 日

Chad Wathington: Thoughtworks Studios 管理总监

Go 是 Thoughtworks Studios(Thoughtworks 的产品部门)在过去 6 年中构建的产品,用于支持 持续交付。它有助于创建和管理自动部署管道。它支持从签入到部署的整个构建-测试-发布过程的自动化。

Thoughtworks 刚刚宣布 我们将 Go 开源——它现在已在 BSD 风格的许可下免费提供,源代码也将很快提供。为了解释这一背景并回答一些常见问题,我采访了 Thoughtworks Studios 管理总监 Chad Wathington

马丁:为什么世界需要另一个持续集成服务器?

查德:Go 不是持续集成服务器。它是为 持续交付 (CD) 而设计的,持续集成只是其中的一部分。Go 支持轻松建模顺序和并行执行、扇入和扇出依赖关系管理以及其他 部署管道 独有的活动。

这难道不是可以通过脚本化 CI 服务器或使用插件来完成的吗?

你可以拼凑出任何东西,但有时你不应该这样做。部署管道应该是你的 CD 工具中的一个一等公民概念,以避免头痛。我见过许多团队,包括 Thoughtworks 的一些团队,浪费大量时间和资源用 CI 工具实现管道。有一些基本的东西缺失,比如如果你有一个以上的简单工作流,则无法清晰地追溯到源代码。

Go 开源是否意味着它作为商业产品失败了?

不,但我们没有达到它作为商业产品的目标。Thoughtworks 是一个 三支柱组织。其中一个支柱是倡导软件卓越,革新 IT。另一个是经营可持续的业务。很难倡导行为的大转变,收取高昂的费用,并与免费的 CI 拼凑解决方案竞争。(我们也是 OSS CI 服务器的忠实粉丝;我们已经开源了三个成功的服务器。)换句话说,我们没有赚到足够的钱来证明没有革命的合理性。把它想象成平衡滑块,它们有明确的最小值。

我们也开始相信基础设施软件需要是 OSS。Go 涵盖的生态系统中的几乎所有东西都是 OSS,从源代码控制和构建到部署和配置管理。这些工具需要社区。虽然 OSS 商业模式在某些方面更难,但如果我们能帮助将持续交付主流化,我们愿意放弃收入。我们的创始人 Roy 是一个坚定的创建公共产品的信徒。

为什么源代码还没有提供?

当你决定免费提供某样东西时,会发生一个有趣的连锁反应。你不能以同样的方式继续收费——这是不道德的。作为回应,你会向潜在客户和现有客户提供大幅折扣,或者告诉他们现在不要付款。这会引起怀疑,令人惊讶的是,人们坚持要付钱给你。当你消除恐惧时,你最终会屈服并告诉个人你正在开源它。当你经历过很多次这样的情况后,你必须进行广泛的公告。无论如何,你都要宣布它。谷歌预先宣布 Android 作为 OSS,惠普也对 WebOS 做了同样的事情。我猜想他们都在试图以类似的方式避免泄露未经宣布的消息。

代码还没有准备好。我们正在努力使开发人员体验变得很棒。我们有一些你期望做的事情,比如清理代码注释中的语言并删除旧的许可证。但是,还有一些其他复杂性。我们使用 Go 在两个数据中心的多个 VM 网格上构建、测试和发布 Go。我们需要创建一个更简单的公共构建基础设施。我们正在 OpenStack 上这样做。我们为 Go 编写的自动化功能测试套件很大,是用 Twist 编写的,Twist 不是开源的,所以我们必须绕过它。还有很多事情要做。

为什么叫 Go,而 golang 已经存在?

Go 最初名为 Cruise,向 CruiseControl 致敬。但是,类似的名称选择造成了混淆,因此在 2010 年 7 月,我们将其更名为 Go。这比谷歌公开发布 golang 晚一点,但当时这种语言并不流行。

这不是一个改变名称的好机会吗?

是的。考虑到让源代码可用的所有工作,我们决定一开始不通过名称来接受进一步的延迟。但是,名称将由社区决定。一旦代码发布,如果社区想要更改名称,我们完全赞成。

Go 和 Cruise Control 之间有什么联系?

Thoughtworks 创建了第一个持续集成服务器 CruiseControl,作为 2001 年的 OSS 项目。在 2007 年,我们开始努力对其进行现代化改造,但我们意识到 CruiseControl 的架构不允许我们想要的网格和一等公民部署管道。目前,CruiseControl 和 Go 没有任何共同之处。

将来你们会对 Go 提供哪些支持?

目前的 Go 团队不会去任何地方。事实上,如果该项目拥有一个繁荣的社区,我们将为它增加更多人员。Thoughtworks 还将提供商业插件和支持。

你们最近发布了另一个名为“Snap”的工具,它们之间有什么区别?

Snap 是我们托管的 CD 作为服务。它适用于具有更简单部署需求的应用程序。我们构建 Go 来解决棘手的复杂 CD 设置。我们设计 Snap 使 CD 本身对将应用程序部署到常见云提供商的团队和组织变得简单。换句话说,Go 的功能广度集中在复杂场景上,而 Snap 的功能深度则侧重于使用约定使 CD 更容易。

你们预计会添加哪些功能?

我们有很多想做的事情,顺序将在很大程度上由社区决定。我们做出了一个有意识的决定,不在团队中设置“产品经理”角色,而是采用更由社区驱动的流程。

添加更多扩展点是优先事项,这样人们就可以更轻松地扩展 Go。围绕使价值流图 (vsm) 除了可视化之外还具有更多与价值流相关的功能,有一些非常酷的想法。许多用户要求添加一些功能,使入门更容易。我们希望将 Go 的身份验证移到插件中,这样人们就可以创建自己的身份验证。

在不久的将来,GitHub 问题中将有一个更好的列表,每个人都可以评论并帮助它们按顺序排列。