解析单存储库：定义、优势与挑战

本篇文章将为您介绍什么是单储存库（monorepo），它与单体（Monolith）有何不同，单储存库有什么优势，以及为什么像谷歌这样的公司会选择使用单储存库。

什么是单存储库？

单储存库是一个在 90 年代末或 2000 年代初被创造出来的术语，用于描述一种将多个项目存储在一个版本控制存储库中的配置。这些项目可以是毫无关联且截然不同的。

使用单存储库有很多重要的原因：

• 它创造了一个单一的事实来源；

• 更容易共享代码；

• 更容易重构代码。

单储存库与单体的区别

单存储库是一个包含独立项目的庞大代码库，而单体是一个服务或一组服务，专用于单一的数据集（或项目），这个数据集可以有许多子项目。但是，通常情况下，我们认为单体是一个包含相关数据的单一实体。

在这里提到的“单体”（monolith）指的是单体应用程序，它是作为单个服务设计的单层应用程序。您可以在一个单储存库中管理一个单体，但也可以将一个单体分成多份，在多储存库中管理。相反的是，一个单存储库不能存储在单体应用程序中，而是通常将单存储库与微服务一起使用。

本篇文章将专注于讨论单存储库。

单存储库 vs.多存储库

单存储库将所有需要的代码放在一个储存库中，而多代码库通常为每个项目创建一个代码库。项目越多，代码库越多。

单储存库通常适用于以下情况：

透明度

在单存储库中，由于许多项目对许多人可见，因此带来了更多的可追溯性和安全特性。

协作

单存储库让协作变得更容易。这是因为每个人都可以访问代码、文件和资产，开发人员可以共享和复用资产。

速度

使用单存储库可以帮助您加速开发。例如，您可以进行最小单位的更改（一个操作即可跨多个项目进行更改）。

多存储库通常适用于以下情况：

如果需要来自多个储存库的数据，多储存库的配置会使问题复杂化。从许多不同的服务器中收集准确数据的协调工作将是非常具有挑战性的。使用多储存库解决方案，为了获得正确的数据，需要连接多个代码库，就像在高峰时段合并到 10 车道高速公路上一样，确保安全合并的关键是协调。

Git 项目

在 Git 中管理大规模的单存储库是行不通的。随着存储库变得越来越大，Git 中的单存储库会变成一个巨大的问题。因此，如果团队使用的是 Git，那么最好使用多储存库。

开源或第三方项目

在某些版本控制系统中，如果要使用开源项目或与第三方团队合作，您可能需要使用多储存库。这样您就可以确保第三方开发人员只能访问他们正在处理的项目。

（当然，在Perforce的版本控制系统Helix Core中，您在单存储库/多存储库中都能实现这一点。您甚至可以在单储存库中将权限限制到文件级别。同时，你还可以通过 Helix4Git 将 Git 项目集成到流水线中。）

单存储库是一个明智的选择吗？

对于许多公司来说，使用单储存库是个不错的选择。您可以将每个团队的所有源代码（一级其他文件/数字资产）保存在一个存储库中。这样可以更轻松地与所有人共享，并保持着单一的事实来源。

在每次提交后，所有开发人员都能查看并使用新代码，这样的话，当许多开发人员在单一代码行上工作时，就能避免繁琐的合并操作了。

以下是一些您应该考虑使用单存储库的原因：

• 您需要单一的事实来源；

• 您希望轻松共享和复用代码；

• 您希望可见性来管理依赖项（例如，如果您进行更改，还会影响哪些内容？）；

• 您希望进行最小级别的更改（例如，一个操作跨多个项目进行更改）；

• 您希望团队进行更多协作；

• 您希望进行大规模更改（例如代码重构）。

如果决定使用单储存库，那么您和一些领先公司做出了同样的选择，比如谷歌。

使用单存储库会面临什么挑战？

单储存库的理念是在一个代码库中进行协同工作，对于代码库中的任何数据几乎没有限制。这听起来很好，但随着单储存库变得越来越大，客户可能需要等待更长的时间才能得到响应。虽然将所有数据放在一个地方的想法很诱人，但如果需要等待几分钟甚至几小时才能得到响应，这样的单数据库又有什么用呢？

单储存库对 DevOps 工具链来说是最具挑战性的。长时间的等待会导致队列拥堵，而任何的错误都会加剧问题。

如果长时间的等待和队列堵塞还不够具有挑战性，那么一个包含了数十年历史记录和文件的单储存库呢？它的巨大规模可能会超过单个磁盘驱动器的容量。您可能会拥有多个 TB 级别的数据，并且许多工具会创建超大的文件。

因此，长期使用单存储库的话，存储方面可能会很昂贵，特别是如果您需要长时间保留数据。解决此问题的方法之一是创建可分布在许多服务器上的单个数据集。这样，您仍然可以在单一的数据源下控制单一的事实，但数据可以通过复制策略放在离用户更近的地方。

通过以这种方式分布数据，用户不需要获取整个代码库树。Perforce Helix Core 的技术能够在单一的事实来源中提供数据的子储存库视图。

示范案例：谷歌为什么使用单存储库？

谷歌是众多使用单存储库的公司中，比较著名的一家。

谷歌很早就决定使用单存储库，并随着公司的发展不断扩大规模。到了 2015 年，谷歌的单存储库已经包含了：

• 86TB 数据；

• 2 亿行代码；

• 9 万个特殊源文件。

那么，为什么谷歌选择并坚持使用单存储库呢？因为使用单存储库是开放和协作文化的关键。

Salesforce、Facebook 和 Twitter 等公司也以使用单存储库而闻名。

当然，如果您选择了使用单存储库，就需要使用支持单存储库的版本控制软件，例如 Perforce Helix Core。

使用 Perforce Helix Core 作为单存储库的版本控制

使用Perforce Helix Core作为单存储库的版本控制系统有许多优势，以下是四个主要的优势：

强大的性能

Perforce Helix Core 是一个强大的版本控制系统，特别适合大规模高性能的需求。

使用 Perforce Helix Core 作为单存储库的版本控制时，它可以处理：

• 从 10 个用户到 1000 个用户，都不在话下（甚至是身处不同地理位置的团队）；

• 无限数量的文件；

• PB 级别的数据。

精细的控制

Perforce Helix Core 提供对大型数据集的细粒度控制，包括用户，项目，文件，地理位置，网络和实用程序（服务）等多个方面。通过在 DevOps 工具链中部署 Perforce Helix Core 的边缘（edge）服务器、Helix Core 代理、Helix Core 代理服务器和工具集成，用户可以在分支级别对行为进行隔离，并获得对共享责任的可见性。

此外，您可以使用 Perforce Streams 在分支级别上隔离用户行为，但您依旧可以了解到跨分支开发时的每个人该分担哪些责任。

高度的安全性

Perforce Helix Core 是很安全的，并且它还具有可定制的安全性控制。您可以使用多因素认证（MFA）等身份验证措施，并可以在文件级别设置访问控制。

这些安全权限能够帮助您在单储存库上与第三方开发人员合作。

灵活性

Perforce Helix Core具有高度的灵活性， 您可以使用 Perforce Streams 来定制和自动化团队的工作流程。

这有助于团队在单存储库上更好地协作。

开发人员可以获得快速反馈和更快的构建速度。从而减少处理工具和流程的时间，更多地专注于提供价值。

开始使用 Perforce Helix Core

Perforce Helix Core为您的所有项目提供了一个单一的事实来源，并为您的团队提供了强大的功能、精细的控制、高度的安全性和灵活性。

文章来源：https://bit.ly/3GJw2vg