共计 3010 个字符，预计需要花费 8 分钟才能阅读完成。
本篇文章将为您介绍什么是单储存库（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
