GitLab首席执行官畅谈当前开发运维实践 GitLab首席执行官畅谈当前开发

文章图片
作者｜Sergio De Simone 译者｜蔡芳芳在整个采访过程中，GitLab 首席执行官 Sid Sijbrandij 谈到了 GitLab 是如何创立的、GitLab 与竞争对手的不同之处、成为“开放”的公司的重要性、GitLab 工程师如何使用持续集成以及成为一家采用远程工作方式的公司意味着什么等诸多话题。GitLab 是 2011 年作为开源云端 Git 解决方案创立的软件开发协作平台。自成立以来，GitLab 一直致力于提供更多的协作工具来支持新的开发实践，如持续交付和性能监控。GitLab 采用了开放核心的开发模式，平台的核心部分是开源的，而附加功能仅适用于付费客户。

关键摘要

现代软件开发使用了许多工具，这些工具覆盖项目的整个生命周期——从规划到性能监控，同时现代软件开发也需要更多沟通。

对 GitLab 来说，开放源码模式不具有可持续性，因此，他们转而采用开放核心模式，为更大的开发团队提供更多的功能。

成为一家采用远程工作方式的公司会遇到很多困难，但借助合适的沟通文化，仍可以成功。

持续集成和部署（CI/CD）在 GitLab 开发过程中发挥了重要作用。采用持续集成和部署使代码审查更有效并缩短了开发周期，这让开发人员能更快地发现错误并从错误中吸取经验。

根据开源开发实践来进行内部软件的开发，又称为内部开源，也是 GitLab 开发过程的基石。

【GitLab首席执行官畅谈当前开发运维实践】InfoQ：可否说明一下 GitLab 是如何诞生的？在 GitLab 成立的时候，GitHub 已经在云端 Git 提供商中占有一席之地，什么样的技术或商业原因驱使你进入同一个竞技场？

Sid Sijbrandij： Dmitriy Zaporozhets 在 2011 年开始了开源项目 GitLab，因为他不满足于当时市场上已有的 git 仓库管理产品。他想要一款他可以负担得起又支持自托管的产品。当时我是一名自学成才的 Ruby 开发顾问。我接触到了 GitLab，它的代码质量和背后的社区都令我印象深刻。
随着开源项目的成功——无论从下载量还是活跃的贡献者数量来看，很显然，市场对开源自托管的 Git 仓库管理软件有很高的需求。虽然 GitHub.com 是一家强大的云端 Git 提供商，但我们意识到许多企业希望能有一个支持自托管的企业级产品，在提供社交编码功能的同时，也提供安全和商业保障。为了满足这些企业开发团队的需求，Dmitriy 和我决定将重点放在为大型组织提供支持的产品和服务上。
来自企业的市场需求是其中一个驱动因素，另一个则是我们的产品愿景，即提供一个集成产品，支持社交编码、持续集成、应用性能监控等功能。

InfoQ：近年来，提供源代码托管服务的网络平台又增加了很多新的竞争者。除了 GitLab 之外，主要还有哪些竞争者，GitLab 的价值主张与对手有什么不同之处？

Sid Sijbrandij： Git 仓库管理产品的主要竞争者还有 Atlassian、BitBucket 和 GitHub。事实上，GitLab、GitHub 和 BitBucket 都是基于 Git 的，因此我们都处在同一标准化水平上，尤其当我们只讨论代码托管的时候更是如此。但是，如果你再想一想那些使用更多现代软件开发实践的新一代开发人员，或者正在进行数字化转换的企业未来的状态，你就能理解 GitLab 是如何从市场上的众多工具中脱颖而出的。我们的愿景和交付速度将我们与竞争对手区分开来。
从愿景方面来看，GitLab 是唯一一款集成产品，它在一个界面上涵盖了从项目规划到应用程序性能监控的整个软件开发生命周期。我们开发的产品，使企业的开发过程能够面向未来。现在，他们可能只是开始用 GitLab 进行源代码管理和持续集成，但随后当他们想要应用 DevOps 实践或实现持续交付时，GitLab 已经内置了所需的工具来帮助他们快速启动这个过程，而无需选用和学习另一款产品。
GitLab 的交付速度和整体开发方式也是一个关键的区别。我们在每月 22 日发布产品的新版本。这意味着我们的客户不必为了新功能的发布而等待太久。
最后一个不同之处是我们的开发方式。GitLab 是一个透明度很高的公司。从我们的源代码到我们的开发路线图，一切都是开放的。作为一家公司，我们认为协作才能得到更好的结果。因此，我们将几乎所有的工作都开放给客户和社区，以找到解决当前和未来挑战的最佳方案。

InfoQ：GitLab 原本是开源的，这是它与竞争对手的主要区别之一。后来 GitLab 改成了开放核心。你是否能解释一下，开源对于 GitLab 一开始的成功的重要性以及后来改为开放核心的理由？开源模式有哪些不足？

Sid Sijbrandij：开源很重要，因为它使我们能够与我们的社区密切合作。到目前为止，我们的开发路线图仍是公开的，我们欢迎所有人对功能进行评论并提出自己的建议，甚至可以对他们想要的功能提交合并请求。这也适用于我们的企业版，该产品的源代码对客户开放。
开源模式的不足之处在于很难基于它建立商业模式。你需要在安装、性能、安全性和依赖升级方面做很多工作。如果一切都是开源的，你只能靠提供技术支持来赚钱。我们在 2013 年学到了教训，由于我们将 GitLab 设计成在安装和维护方面对用户十分友好，当一年的订阅到期之后，客户很快发现他们在那一年里根本没有用到技术支持。因此，靠提供技术支持建立商业模式是不可持续的。反之，我们发现有一些特性和功能对于大型开发团队（如企业组织）更有用。通过为拥有大型开发团队或更高级需求的客户提供额外的功能，我们能继续通过我们的产品来展示我们的价值。当然，我们仍然提供支持和培训，因为我们希望通过我们提供的解决方案使团队能够专注于核心业务，而不用担心工具的使用问题。

InfoQ：你一开始进入软件开发行业的时候是一名 Ruby 程序员和开发顾问。GitLab 最初完全用 Ruby 编写只是巧合吗？有什么重要原因让你们选择用 Ruby 编写 GitLab？

Sid Sijbrandij：在为一家潜艇公司工作了五年之后，我发现了 Ruby，当时对 GitLab 还一无所知。我还记得，当时我认为这就是我一直在寻找的编程工具，它将编程从繁琐而乏味的活动变成了能让人乐在其中的趣事。
我很快自学了 Ruby，并在不久之后转换职业生涯，成为了一名开发人员。在多家公司担任顾问几年后，我遇见了 GitLab，并爱上了它。虽然 GitLab 最初是用 Ruby 编写的，但一些对性能比较敏感的部分已经用 Go 重写了。
Ruby 使 GitLab 能够月复一月不断地为平台带来巨大的改进。大量的测试套件和库也保证了项目的可维护性。

InfoQ：后来 GitLab 的有些部分已经用 Go 重写了。是什么推动了这样的改变？这种改变带来了什么好处？未来 Ruby 和 Go 在 GitLab 项目中分别还会怎么变化？

Sid Sijbrandij： Ruby 对多线程支持得不太好，很容易出错。而 GitLab 的性能敏感部分（例如访问 git 存储库）又需要用到多线程，因此我们将这些部分用 Go 重写了。我们对这一改变非常满意，因为它使一切变得更快了。目前我们正在 Gitaly 项目中用 Go 重写 git 访问部分的代码。

InfoQ：随着时间的推移，GitLab 已经拥有了非常庞大的开发团队，处理着许多不同的组件。关于如何使这些团队或组件高效地沟通，能否分享一下你学到的经验或教训？

Sid Sijbrandij： GitLab 雇用了在世界各地远程工作的员工，我们在 38 个不同国家拥有 170 名员工。我们一直是一家采用远程工作方式的公司。
雇用远程工作的员工可能会遇到很多困难，但是我们花了大量的时间来构建并不断完善我们的员工手册。现在它成为了一份流动文档，其中详细介绍了我们的内部流程、团队资源等。我们的员工手册是存储所有重要信息的“真理之源”。GitLab 的每个员工都可以访问这个文档，并且他们也可以很方便地查找文档以了解工作中的项目信息或公司信息。
尽管员工遍布全球，但我们营造了促进沟通和联系的文化氛围。我们早期实行的方法之一是每日团队电话。这个电话持续约 25 分钟，员工可以利用这段时间分享他们最新的社交编码成果。在进行通话之前，负责不同功能特性的小组会向整个团队进行更新部分的展示，并针对他们正在开展的工作进行说明。所有这些更新都会使用 Zoom 记录，并上传到我们的 YouTube 频道。
我们还为员工提供了另一项选择，他们可以通过申请旅费补助到世界任何一个地方旅行工作。如果 GitLab 员工想与另一个国家的另一位同事合作，他们可以向自己的经理提交旅行计划，一经批准，该员工将获得高达 2000 美元的旅费补助。

InfoQ：你最近推出了“跟我学编程”这一播客节目，节目听众提出的问题中有一个是关于员工激励的。除了你在那已经分享过的内容之外，你能否再跟我们解释一下，在 GitLab 平台每月发布一次更新的如此漫长的时间里，你是如何不断保持 GitLab 团队成员的动力的？

Sid Sijbrandij： GitLab 非常有幸能拥有一群了不起的人在这里工作，而这自然对保持员工的动力有所帮助。但我也认为我们有意在整个公司中传递我们的愿景、价值观和透明的沟通方式。我们的愿景往往代表了整个公司的心声。我们都对我们的产品充满热情，对于我们能向社区和客户提供的好处也感到非常兴奋。我们的价值观，即关注结果和效率，也有助于提升员工的动力。
GitLab 认为认可也是激励员工动力的一种工具。例如，我们有一个感谢频道，你可以随时点进去查看和庆祝彼此的成果和努力。最后，我们的沟通风格有助于保持动力。当员工不了解公司的发展情况或者不明白自己的角色如何促成公司目标时，就很容易失去动力。我之前提到的功能小组每日更新展示就有助于确保公司中的每个人都知道其他团队正在做什么。

InfoQ：定期而频繁地发布大量版本的优点和缺点分别是什么？这些年来 GitLab 管理这个过程的方法有什么变化？

Sid Sijbrandij：一开始我们就决定不管公司怎么发展，我们都想一直做一个致力于为开发人员提供最新最好的工具的组织。为了做到这一点，我们制定计划在每个月的 22 日发布更新，以便跟上开发人员使用需求的变化速度。近几年，我们开始提早给候选发布版本拉取分支。目前我们会在每个月 7 日完成这项任务。

InfoQ：GitLab 一直坚持频繁、定期发布的理念，这个理念与近年来出现的持续集成和部署的关键思想有关，你如何看待持续集成和持续部署正在改变软件行业及实践这一说法？

Sid Sijbrandij：持续集成和持续部署已经快速成为开发最佳实践，它被证明可以帮助团队更早地捕获错误和更频繁地发布更新。随着持续集成和持续部署成为最佳实践，越来越多的团队在开发过程引入持续集成，并且最终也将引入持续部署。采用持续集成和持续部署符合“左移”概念，使更多开发人员能够将更早也更频繁的测试作为开发过程的一部分。持续集成和持续交付的做法使开发团队得以提高开发质量并缩短开发周期。这也是我们开发 GitLab 并将持续集成和持续部署功能与源代码管理功能集成在一起的原因。

InfoQ：持续集成和持续部署在你们的开发过程中扮演着什么样的角色？

Sid Sijbrandij：采用持续集成和持续部署的组织将更加高效。我们已经体会到了这一点，并认为它对于开发过程至关重要。我们在每次提交代码时都会运行持续集成测试。我们不仅使用 GitLab 开发 GitLab，而且还使用它来开发我们的网站，所以 GitLab 持续集成在我们的开发过程中起着十分重要的作用。
我们使用 GitLab 持续集成来改进开发过程，用它来自动执行部分代码审查工作。我们的开发人员多于开发组长。由于需要每个月进行一次发布，我们一直在寻找能够节省开发组长时间的方法，以便他们能够高效地工作并审查开发人员提交的所有功能。为了改进这个过程，我们做了一些工作，包括编写可以捕获常见错误的测试脚本。如果这些错误只出现一次，那它们也许不需要花很多时间修复，但是当我们考虑到在版本发布日之前所有的开发人员都在合并新功能，哪怕只是一点点自动化都会有所帮助。我们将 GitLab 持续集成功能集成到了我们所有版本的 GitLab 中，以期更多的团队可以提高代码质量，最好还能加快交付速度。

InfoQ：GitLab 是如何把持续集成和持续部署作为关键部分融入其价值主张的？是你们在开发 GitLab 时得到的经验使你们意识到它的重要性，还是有别的因素促使你们这么做？

Sid Sijbrandij： GitLab 的创始人 Dmitriy 想找一个好的持续集成解决方案来测试 GitLab。最受欢迎的开源产品是 Jenkins，但他不喜欢以前升级 Jenkins 的体验。就像开发 GitLab 一样，他想着这能有多难，然后重新开发了一个属于他自己的持续集成模型。他没有请求任何人的许可，只是动手去做并做成了。
一年之后，我们有一些用户提出了有关持续集成的问题，我们分配了两个人将它做得更具可用性。我们的团队领导建议将其作为 GitLab 的一部分，但 Dmitriy 最初觉得这与将“小而锋利的工具”结合在一起的 unix 哲学相违背。
经过对持续集成和持续部署的价值进行多次公司内部辩论之后，我们最终确定要将它整合到 GitLab 中。结果超出了我们的预期。从那时起，我们从未回头。我们开始整合工具来实现紧急的特性。我们将成功加倍放大，现在也开始把持续部署和测量指标整合到 GitLab 平台中，包括审查应用程序、金丝雀部署和循环分析等功能。

InfoQ：从你的角度来看，成功实施持续集成和持续部署的关键点是什么？

Sid Sijbrandij：在成功实施持续集成和持续部署之后，开发人员将能够看到一些几年前不可能看到的开发活动。例如，利用持续集成和持续部署，开发人员现在可以检查代码的实时预览，一旦创建了变更立刻就能看到，可以观察每一个小集群的部署情况，同时监控每个环境的状态。
在使用持续集成和持续部署工具之前，开发人员必须等到整个开发生命周期结束才能确定是什么错误导致了代码中的缺陷。这个过程往往是耗时、乏味和低效的。它也可能导致开发过程延期，最终影响发布日期并给开发人员造成金钱损失。
如果你的持续集成和持续部署的工具成功整合，你会发现开发团队的速度变快了。开发人员全面了解开发过程后，就可以在此过程中更早地发现错误，并在错误造成更大的影响之前从中得到教训。这点很重要，因为开发人员现在可以更快地学习了。

InfoQ：谈到开源实践，GitLab 长期以来一直是内部开源思想的坚定支持者，内部开源是 Tim O'Reilly 提出的一个术语，指的是在公司内部使用开源技术。在你看来，最重要的开发实践是什么？自 2014 年以来，它们是如何发展的？

Sid Sijbrandij：自 2014 年以来，我一直坚信，开源组织需要实践内部开源技术。其中最重要的开发实践是公司内部的每个项目都应是开放的。GitLab 在公共和私人之间有一个特殊的设置称为内部。这个设置允许公司内部的所有成员查看项目，同时又能将服务器上拥有账号的外包人员排除在外。
这样做可以让不同的团队成员重新组合和重用代码，使组织变得更高效。这也能提高安全性，因为开发人员可以更容易地发现和识别代码中的安全漏洞。在过去三年中，越来越多的企业使用开源代码。今天，越来越多的开发人员熟悉分支工作流程，在这种工作流程中你无需原代码库的写入权限就可以提出建议。

关于采访对象GitLab 首席执行官 Sid Sijbrandij 最初是私人潜艇公司的程序员，后来自学 Ruby 编程并成为 Ruby 程序开发人员，经介绍进入 GitLab。自 Sid 担任公司高层后，GitLab 发展迅速，在由 August Capital 发起的 B 轮投资中获得了 2000 万美元的投资，并承诺为 IBM、Macy's 和 Verizon 等客户的完整开发生命周期提供解决方案。
2017 年，有哪些值得关注的运维技术热点？智能化运维、Serverless、DevOps ......CNUTCon 全球运维技术大会将于 9 月上海举办，12 位大牛联合出品，揭秘最前沿运维技术，推荐学习！