在回答这些问题时，我想看看：
尝试给出产品的实际定义，这提供了在现有代码库中实际描绘产品的实用准则。
根据此工作定义，制定一项实际执行拆分的计划。我们可以简化假设，即代码库是由实现连续集成和持续交付的全自动sdlc处理的。也就是说，每个分支都由在当前代码库中实现的自动化测试套件进行验证，并且每个合并到某个“魔术”分支中都会生成经过测试和部署的产品工件。 （产品伪像是例如源tarball，文档，二进制软件包，Docker映像，AMI，unikernels。）
如果该计划能够说明如何规避
问题，那么该计划是令人满意的。分割
自动化测试程序如何与预先存在的整体存储库和拆分存储库相关？
自动化部署程序如何与预先存在的整体存储库和拆分存储库相关？
将自动部署的代码存储在哪里程序本身？
存储的基础结构，监视和高可用性策略在哪里？
如何确保开发人员一次只需要一个代码库（但可能使用其他代码库的伪像）。像git-bisect这样的工具
边际说明：与膨胀的存储库模型相比，每个VCS存储库拥有一个产品的好处
拥有几个小型存储库来保存代码库相对于“膨胀存储库”方法，特定产品具有以下优势：
使用膨胀存储库，当产品不稳定时，很难回滚发布，因为历史与其他产品混合在一起产品历史记录。
拥有庞大的存储库，很难查看项目历史记录或拉动，而对于小型存储库，我们更有可能阅读此信息。 （这可能是像git这样的VCS特有的，与svn不同，我们无法检出子树！）
使用膨胀的存储库，我们在开发时必须做更多的分支舞蹈。如果有N个存储库，则可以在N个分支上并行工作；如果只有1个存储库，则只能在一个分支上工作；或者有大量工作副本，这也很麻烦。
在存储库中，日志提供了该项目的热图。他们甚至可以用作开发团队中知识传播的代理人：如果我三个月以来没有从事回购X，最好将我分配到一个从事回购X的团队中，以便我随时了解发展情况。在该组件中。
使用小型存储库，更容易获得组件的清晰概述。如果所有内容都放在一个大型存储库中，则没有描绘每个组件的明显伪像，并且代码库可以轻松地移向泥潭。
小型存储库迫使我们在组件之间的接口上工作。但是由于我们希望有一个好的封装，无论如何我们都应该做这件工作，所以我认为这对于小型存储库是一个优势。
有了几个小型存储库，拥有多个产品所有者就容易多了。
通过几个小型存储库，可以轻松地获得与完整存储库相关的简单代码标准，并且可以自动对其进行验证。
#1 楼
这是一个引人入胜的问题，对于该问题可能实际上并不存在。我赞赏您在将问题与VCS保持上下文相关的同时，它自然会自动扩展到基础结构设计和实施计划。尽管如此，看来我们许多人都在进行这种过渡，这可能令人兴奋，但同时又令人沮丧和痛苦；并且我想分享自己的经验和观点，尽量不要太学究，并且只是因为我可能不是一个好工程师，也不要太无聊。
设计
基础设施和体系结构应该一起编写现代软件。如果需要，可以紧密耦合。使用这些词听起来可能很奇怪，但是我们在这里并不一定要讨论代码本身：我的意思是它们必须是同一蓝图的一部分。当云层到来，人们开始为他们编写软件时，然后有多少人意识到，将泥球放在那儿，它们只是在不同的地方是相同的泥球（？）也许一些有远见的人可以预见到，而且他们今天可能会在开发人员中工作。由于devop只是一个时髦的词汇，对于不同的人来说具有许多不同的含义，因此我已经看到了devop团队将在每次架构会议中所坐的地方。其他仅自动化的地方。为了实现这种转变，我们必须努力争取坐在那里。
信心
必须始终隔离这种转变，从某种意义上说，这是一贯的历史切割必须存在，仅提供过渡本身，并且仅提供过渡，而没有任何其他更改（经过几个月的准备）。有什么信心可以批准并按下红色按钮？
我的意思是代码库必须更改以适应新的VCS结构，并且在开发过程中很难使其合并。 （对于这个问题，可能会有一些促进策略，我将在稍后讨论一种常见的策略，该策略可以帮助并行化开发。）
我敢打赌，唯一的方法就是行为测试，应该启动相同的行为测试套件，以使用新的代码库验证旧的代码。我们没有在此处验证应用程序的行为是否正常，但是该过渡不会改变其行为。测试失败可能是一件好事！如果它们继续失败！
实际上，对泥球进行良好的测试是非常罕见的。通常，代码是非常紧密地耦合在一起的，并且对于大多数传统代码而言，很可能不是使用测试驱动的方法开发的，甚至不是单元测试。
如果缺少此类测试代码，则应首先写。
策略
是的，过渡必须保持隔离；但同时又整合了。我知道我可能在这里听起来很疯狂，但是我找不到其他词来形容信心如何保持业务发展。很少（甚至根本没有）公司愿意停止开发大型整体代码库，以腾出空间进行这种过渡，而我们也不是一味地做到这一点。也许数百名开发人员可能会继续为代码库做贡献（我在这里使用来自POV的篡改词）。虽然我们的工作必须处理特定的快照以提供信心，但我们必须保持自己的基础（这里不是git的意思），以避免永远落后。
这里的实施策略可以提供不同的经验。一个常见的开发思路是在需要与核心交互时包装/适应（使用可选的重新安排方案公开端点）较新的实现分支（在这种情况下，位于其他存储库中）。采用这样的策略进行过渡以及重构，可以同时为VCS过渡提供POC方案，并在以后逐步进行。看到它就像雕刻泥球。是的，生活提供了很多有趣的东西。
技术债务
企业管理领域开始理解技术债务并将其考虑在内。不，请scratch，不正确。收集度量和质量数据变得越来越普遍，但是就静态代码分析，代码审查，行为测试结果和性能而言，并生成精美的报告和所有内容……要使企业持续接受，仍然非常困难。重构方法。它的商业价值。 “我们正在遵循一个敏捷的过程，这不会带来任何功能上的增强，不是吗？”。基本上，这样做是在消除技术债务的存在。
我认为这是缺少的必要步骤，无法启动从整体到微服务架构的任何过渡。
重新聚合<毕竟，您可能仍想提供一个类似于存储库的视图，您可以在其中构建多个产品。出于任何原因，即curr / next版本，多品牌，客户群。在这种情况下，像Google repo这样的工具可能会有所帮助。我自己从来没有用过，但是我知道我需要一天。
集成测试
对于微服务，集成测试采用了“测试自己的API”的不同上下文。可以而且将存在更高层次的测试，功能或性能，但是如果没有适当的集成测试，它们是否意味着很多？
就像进行集成测试而不进行单元测试一样。当然不是。这就是为什么如果需要git bisect，将在微服务存储库分支中执行它，而不必在mudball存储库中运行它。
PS。这是草稿，我的英语不好，有一天我会解决
评论
这种解决方案的关键部分是一个体面的工件存储库（例如，工件存储），它使您可以将依赖组件与同一存储库分离。 IOW而不是共享代码（一个仓库），而是发布和使用构建的库（工件）。这也是开始此类工作的好地方，因为您可以一个一个地重构/提取模块。肯定是。 :)
实际上，我们正在研究一个非常相似的问题。我们正在考虑的方法是拥有一个没有任何代码提交给它的主存储库，以及其他存储库作为子模块附加。但是我们仍然需要找到正确的工具和流程的集成来完成它。当我们弄清楚细节时，我将组成一个详细的答案。
如果产品共享（平台/产品无关）代码，则事情可能会变得更加复杂。或者，如果每个产品系列都有通用代码。并不是说拆分不是一个好主意，只有部分的管理以及优缺点列表会有所不同。
我认为您使用git-bisect的第6个项目符号缺少某些内容。我想知道是否应该或多或少地要求一本书，所以不应该将其分解为单独的问题。由于产品的定义非常主观（可能会有所不同），所以我认为SE网站上的问题实际上有点过高。太宽泛或太基于意见。