最佳实践-单一或多个源代码存储库

Question

如前所述，这里：

CI的主要目的是防止集成问题，也就是所谓的“整合地狱”。

我们的项目是一个3层web应用程序，具有前端(角6)、后端(Springboot)和数据库层。

对于前端代码(角6)，我们有一个源代码存储库(.git)。

对于后端(SpringBoot)，我们有两个源代码存储库(.git)

对于数据库层(Java& MySQL)，我们有三个源代码存储库(.git)

目前，代码有单元测试用例。

根据维基中提到的CI工作流程，

当开始进行更改时，开发人员将获取要工作的当前代码的副本。当其他开发人员将修改过的代码提交到源代码存储库时，此副本逐渐停止反映存储库代码。不仅可以更改现有的代码库，还可以添加新代码以及创建依赖关系和潜在冲突的新库和其他资源。代码分支退出的时间越长，当开发人员分支重新集成到主线时，多个集成冲突和失败的风险就越大。当开发人员向存储库提交代码时，他们必须首先更新他们的代码，以反映存储库中的更改，因为他们获取了他们的副本。存储库包含的更改越多，开发人员在提交自己的更改之前必须做的工作就越多。最终，存储库可能变得与开发人员的基线非常不同，以至于他们进入了有时被称为“合并地狱”或“集成地狱”的4.，在那里集成所需的时间超过了进行原始更改所需的时间。持续集成涉及到早期和经常的集成，以避免“集成地狱”的陷阱。该实践旨在减少返工，从而减少成本和时间。

( 1)为了执行集成测试，S建议在单个回购(.git)中使用源代码(ar角_前端/java_back_end/database)？

2)维护完整代码的单一源代码存储库(完全堆栈)是一种良好的实践吗？用于运行CI/CD管道..。

Answer 1

您的报价与非常原始的CI系统相关，这些系统构建在较老的VCS之上，它不支持可靠的合并，并且提供了一种存储和共享更改的方法，然后才将更改提交给主线。他们正在实时跟踪干线的最新状态。因此，开发人员还要求do尽可能快地向主线提供他们的更改。如果您正在使用这种方法，那么有多少存储库并不重要。你只要把它们的头像统统整合起来。

现在，在将更改合并到开发主线之前，通常会在特性分支中跟踪更改，并为这些特性分支运行CI构建和测试。这确保了在合并的时刻有很高的信心，改变是正确的。此外，它还可靠地存储在合并之前的更改，这样它们就不会因为事故而丢失。

有了新的方法，拥有多个存储库就成了负担，因为开发人员必须在不同的存储库之间同步未合并的分支。但是，在同一个存储库中有几个不相关的程序也有缺点- (1)它只是要获取更多的数据，(2)它将使他们的历史与其他项目的变化杂乱无章，(3)它防止了一些项目的外包而不向开发人员公开其他项目。

我的观点是，最佳粒度是每个分发单元或重用组件的存储库。例如，如果您有平台A和B的服务和移动应用程序，那么将有3个存储库。如果他们共用一些L图书馆，图书馆就会增加4-1个.将它们合并到更大的存储库中不会带来任何额外的好处--在更改它们之间的接口时，您将不得不考虑兼容性问题。