有些人似乎在推广mono repos。当我计划将代码迁移到Gitlab时，我想借此机会了解如何将其制作成monorepo。我有三个问题：
假设我将所有服务放在同一个项目中（Gitlab仓库称为Projects，对吗？），然后可以获取CI / CD系统来构建每个组件吗？
我可以让Gitlab向我的容器注册表中发送几个图像吗？
假设我对一项服务进行了更改，并希望在部署之前确保它可以与我的其他服务一起使用，如何做到最好？设置集成测试，这些条件会决定我与其他服务的交互是否成功提交？
#1 楼
Monorepos很不错，因为它消除了多个项目之间的技术约束。但是，这确实打开了存储库中其他复杂问题的大门（命名约定，跨团队依赖性，合并冲突增加等）。我没有使用CircleCI的经验，但是我将根据我使用的其他CI工具提供一些意见。我看不出您为什么无法这么做的任何原因。在您的CI / CD系统中，您将使用主monorepo作为源存储库，然后引用其中的特定项目目录，而不是引用各个源存储库。
从GitLab 9.1版本开始，似乎已受支持。您可以执行此操作，但是我认为这会大大降低您的开发速度，并且如果您有很多提交，则会占用大量资源。需要考虑的两个关键点是：在每个生产版本之前，您应该对基础结构中的所有项目运行完整套件测试。这是确保所有项目依赖项都不会中断的唯一方法。
测试/设置必须并行运行。这样，您的完整存储库测试速度将是存储库中最长的测试/配置时间。 （作为副作用，它着重于加快最慢的测试速度）
评论
您是否真的想通过在正式发布产品之前运行测试来找出打破依赖关系（或任何其他此类问题）的方法？如果您不喜欢在此类测试中发现的内容，您如何可靠地满足发布时间表？ ;）
–丹·科尼莱斯库（Dan Cornilescu）
17年11月13日在15:45
是的，这是真的。我的回答是量身定制的，至少意味着您应该在正式发布产品之前运行这些测试。但是，您认为在每次提交时配置和测试整个基础架构是否合适？这可能是一个非常昂贵且耗时的决定。我认为任何一项决定都需要根据具体情况进行评估。一种折衷办法是每晚进行一次完整的基础架构测试：)
–普雷斯顿·马丁（Preston Martin）
17年11月13日在15:54
潜在的高成本（我知道经常会提高）也应该与由于发现问题或发行错误发行而不发行版本的成本进行比较。您的妥协可能是可以接受的，但这取决于项目，规模，团队的质量等。我同意逐案评估的观点。即使不对每个更改都运行测试，也可以实现可靠性，但仅通过使用提交前测试（而不是提交后的传统CI）进行提交条件即可。
–丹·科尼莱斯库（Dan Cornilescu）
17年11月13日在16:21
@PrestonM我真的很想为每个提交做全面的集成测试。这样一来，我知道我一经测试就可以随时部署更改。我同意这会为每次提交提供更长的周转时间，但这是我愿意付出的代价。
– langkilde
17年11月13日在18:33