当我们的联合创始人兼工程研究员 Dmitriy Zaporozhets 决定构建 GitLab 时，他选择使用 Ruby on Rails，尽管当时主要使用 PHP。GitHub是GitLab的灵感来源，也是基于Rails的，考虑到他对框架的兴趣，这是一个合乎逻辑的选择。GitLab首席执行官Sid Sijbrandij认为他的联合创始人做出了一个不错的选择：

“效果非常好，因为Ruby on Rails生态系统允许你以高质量塑造许多功能，”他解释道。“如果你看看GitLab，它有很多功能。软件开发非常复杂，为了帮助解决这个问题，我们需要很多功能，而Ruby on Rails就是一种方法。因为所有这些最佳实践都在你快乐的道路上，所以当你发布像 GitLab 这样的东西时，这也是保持代码一致性的一种方式。你被引导去做正确的事情。

取决于有用的宝石
根据 Sid 的说法，红宝石在 GitLab 的构建中扮演着不可或缺的角色，它装载了一千多个非独特的宝石。他称Ruby on Rails框架“非常固执己见”，他认为这是一个强大的环境，可以构建像GitLab这样的复杂应用程序。

“它周围有一个很棒的生态系统，它的宝石可以对你如何做事做出假设，在这方面，我认为Ruby on Rails生态系统仍然没有标准，”他说。“如果你看看我们的 Gemfile，它会告诉你我们可以构建的依赖关系有多大。Ruby on Rails有惊人的肩膀可以站立，在任何其他框架中开发GitLab都会慢得多。

克服挑战
所有这些并不是说使用Ruby on Rails构建GitLab没有挑战。性能一直是我们的开发人员在以多种方式改进方面取得长足进步的问题，包括用 Go 重写代码和使用 Vue 框架。后者用于重写经常访问的页面，例如问题和合并请求，因此它们的加载速度更快，从而改善用户体验。

Go 用于解决影响加载时间并减少内存使用量的其他问题。

“Ruby 是为开发人员优化的，而不是为了在生产环境中运行它，”Sid 说。“对于经常受到打击并且必须非常高性能的东西，或者例如，必须在系统 IO 上等待很长时间的东西，我们在 Go 中重写它们......我们仍在努力让 GitLab 使用更少的内存。因此，我们需要启用多线程。当我们开发 GitLab 时，这在 Ruby on Rails 生态系统中并不常见。现在它更常见了，但由于我们现在有如此多的代码和如此多的依赖项，因此我们到达那里将是一条更长的道路。这应该会有所帮助;它不会让它变得非常快，但至少它会使用更少的内存。

将Go 添加到 GitLab 的工具箱导致了一个名为 Gitaly 的独立服务的创建，该服务处理所有 Git 请求。

以 GitLab 的使命为基础
Ruby on Rails框架的有组织，结构化的风格符合我们的核心使命。因为 Rails 是精简的，任何人都可以跳入 GitLab 并参与其中，这使得它从一开始就对 Sid 特别有吸引力。

“我们的使命是每个人都能做出贡献，”他解释道。“因为Ruby on Rails对哪些部分去哪里固执己见，所以新开发人员更容易进入代码库，因为你知道人们把东西放在哪里。例如，在你进入的每个厨房里，你永远不知道刀和盘子在哪里。但是有了Ruby on Rails，你进入厨房，它总是在同一个地方，我们希望坚持这一点。

在你进入的每个厨房里，你永远不知道刀和盘子在哪里。但是有了Ruby on Rails，你进入厨房，它总是在同一个地方，我们希望坚持这一点。

“当我打开这个项目并在 Dmitriy 开始一年后第一次看到它时，我真的很受鼓舞。我打开它，它是惯用的Rails。他遵循所有的原则。他没有尝试尝试某种他感兴趣的时尚。他把它变成了一个生产应用程序。Dmitriy仔细审查了所有的贡献，以确保他们遵守这些惯例，现在仍然如此。我认为我们有一个非常好的代码库，允许其他人在其上构建。我们的子价值观之一是无聊的解决方案：不要做任何花哨的事情。这是为了让其他人可以在它之上构建。我认为我们在这方面做得很好...我们真的很感谢 Ruby 是一个如此稳定的生态系统，让我们可以在此基础上再接再厉。

封面图片由Elvir K在Unsplash上拍摄

翻译自

Why we use Ruby on Rails to build GitLab|GitLab

Ruby on Rails（官方简称为Rails，亦被简称为RoR），是一个使用Ruby语言写的开源Web应用框架。 

Ruby on Rails已死？GitLab：我还在用呢！_开源头条的博客-CSDN博客