1
如何实现从“一个用于所有产品的大型VCS存储库”组织模型到“许多小型VCS存储库”模型的平稳过渡？
通常的情况是，某些VCS系统中存储库所拥有的产品的代码库会发展到可以认为该代码库包含多个产品的地步。在多个VCS存储库中拆分代码库，每个VCS存储库专用于单个产品，可以利用多种好处（请参见下面的膨胀存储库模型，每个VCS存储库都有一个产品的好处）。从技术方面来说，拆分代码库是一个相当简单的步骤，因为大多数VCS支持此操作。但是，拆分可能会引起与自动化测试，持续交付，服务集成或监视有关的工程问题（请参阅拆分所引发的问题）。）因此，计划进行这种拆分的组织需要知道如何尽可能平稳地执行此过渡，即在不中断其交付和监视管道的情况下。第一步可能是更好地理解项目的概念，以及如何在整体代码库中描述拆分。 在此问题的答案中，我希望看到： 尝试给出产品的实际定义，这提供了在实际代码库中实际描绘产品的实用准则。 根据此工作定义，制定一个实际执行拆分的计划。我们可以简化假设，即代码库是由实现连续集成和持续交付的全自动sdlc处理的。也就是说，每个分支都由在当前代码库中实现的自动化测试套件进行验证，并且每个合并到某个“魔术”分支中都会生成经过测试和部署的产品工件。（产品文物是如源压缩包，文档，二进制软件包，多克尔图像阿美族，unikernels。） 如果它说明了如何规避 分裂引起的问题 自动化测试程序如何与预先存在的整体存储库和拆分存储库相关联？ 自动化部署过程如何与预先存在的整体存储库和拆分存储库相关联？ 自动部署过程本身的代码存储在哪里？ 存储的基础架构，监视和高可用性策略在哪里？ 如何确保开发人员一次只需要一个代码库（但可能会使用其他代码库的伪像）。 像git-bisect这样的工具 边际说明：与膨胀的存储库模型相比，每个VCS存储库拥有产品的好处 与“膨胀存储库”方法相比，拥有多个小型存储库来保存特定产品的代码库具有以下优点： 使用膨胀的存储库，当产品不稳定时，很难回滚发布，因为历史记录与其他产品历史记录混合在一起。 对于庞大的存储库，使用小型存储库很难查看项目历史记录或请求，而我们更可能阅读此信息。（这可能特定于git之类的VCS，与svn不同，我们无法检出子树！） 使用庞大的存储库，我们在开发时必须做更多的分支舞蹈。如果有N个存储库，则可以在N个分支上并行工作；如果只有1个存储库，则只能在一个分支上工作，或者有大量工作副本，这也很麻烦。 日志中有几个小型存储库，提供了该项目的热图。他们甚至可以用作开发团队中知识传播的代理人：如果我三个月以来没有从事repo X，最好将我分配到从事repo X的团队中，以便我随时了解发展情况。在该组件中。 使用小型存储库，更容易获得组件的清晰概述。如果所有内容都放在一个大的存储库中，则没有描绘每个组件的明显伪像，并且代码库可以轻松地移向泥潭。 小型存储库迫使我们致力于组件之间的接口。但是由于我们希望有一个好的封装，无论如何我们都应该做这项工作，因此我认为这对于小型存储库是一个优势。 使用几个小型存储库，可以轻松拥有多个产品所有者。 使用几个小型存储库，可以轻松地拥有与完整存储库相关的简单代码标准，并且可以自动进行验证。