monorepo

CodePen的DevOps实践：回归单体代码库(Monorepo)的优势

虽然我不是大型DevOps专家，但CodePen正在转向单体代码库(monorepo)，这与多个小型代码库的系统相比，具有诸多优势，至少对我们而言是如此。您的挑战和结论可能完全不同。

我读了Ben Nadel的“为什么我在InVision将微服务合并回单体架构”后，想到了这一点。尽管我们的结论相似，但我可以看出他面临着一组完全不同的问题。

微服务解决技术和人员问题

技术问题是指应用程序的某个方面给基础设施带来了过大的负担，进而可能导致糟糕的用户体验(UX)。例如，图像处理需要大量的CPU。如果此CPU负载过大，它可能会开始使应用程序的其他部分缺乏处理资源。这可能会影响系统延迟。而且，如果情况严重到足以影响系统可用性。

人员问题另一方面，与应用程序几乎无关，而与团队的组织方式有关。在应用程序的任何给定部分工作的人员越多，开发和部署就越慢，越容易出错。例如，如果您有30名工程师都在争先恐后地“持续部署”(CD)相同的服务，那么您将获得大量的排队；这意味着，许多本来可以交付产品的工程师实际上是在等待轮到他们部署。

单体代码库(Monorepo)的优势（对我们而言）

• 一统天下。您只需git pull一个代码库，就能与其他人完全同步，并拥有完整开发环境所需的一切。
• 井然有序。GitHub上的操作位置不会造成混淆。您针对单体代码库进行拉取请求。您在单体代码库上打开问题。这避免了分散的活动而导致信息丢失。
• 代码共享。您可以共享代码。在整个代码库中共享实用程序或组件特别有用。我们尝试过将共享部分发布到npm供其他代码库使用，但与在一个地方拥有代码相比，该工作流程很笨拙。
• 统一维护。只有一个代码库，不存在旧的和被忽略的代码库。对于我们的小团队来说，拥有数十个代码库意味着其中一些代码库具有旧的过时依赖项、旧版本的Node、与其他代码库不同步的代码风格检查和格式化规则等。

单体代码库(Monorepo)的劣势（对我们而言）

• 部署复杂性。我认为我们最初拆分代码库的主要原因是这些代码库中的代码需要部署到不同的位置。它们可能代表某个单独的Lambda或其他服务器上的单独服务。单个代码库意味着更容易连接特定于该服务器/服务的组件，例如CI/CD。

是的，我知道这有争议。

我其实不太在意。我不会像空气炸锅爱好者和CrossFit狂热者那样对此过于激烈。这是Matt Klein对单体代码库的强有力论证。

我只是说：这对我们来说非常有用。我可以看出其他公司的情况会有所不同。我可以看出，与承包商合作的公司可能希望将其访问权限限制在小于整个单体代码库的范围内。我可以看出git代码库可能会变得庞大而难以管理。这些目前对CodePen来说都不是问题，因此单体代码库的优势胜出。

以上是monorepo的详细内容。更多信息请关注PHP中文网其他相关文章！