+44 203 858 0803 hello@hip.property

单声道与微型回购的争论在开发者圈子中肆虐,虽然它不像标签与空间那样具有分裂性,但我在过道的两侧都花了一些时间。

在我上一份工作 - 这是一家FinTech咨询公司 - 我们广泛使用了微型回购。 这对一个项目非常有益,而另一个项目我们发现它造成了更多的痛苦而不是利益。 所以,当我加入HiP时,我决定我们最初使用单声道repo进行构建,并在它吸入时进行切换。 到目前为止,它还没有。

但是,我们确实有一些不同的存储库 - 我们的平台,包括所有库,微服务和客户端/应用程序代码都存在于一个单一的存储中。 但是,我们的一些工具是我们构建链的一部分 - 比如 蒂诺越狱 住在自己的回购。 这感觉就像一个务实的平衡。

双方都有强烈的争论,我可以看到每种方法的优点。

关于微回购

Micro-repos,(你有许多独立的回购 - 通常每个工件一个)与微服务的思维方式很好地契合。 我们最终使用了 myrepos 作为我们工具链的关键部分,因为它使结账和IDE体验非常愉快。

在下列情况下考虑使用微回购:

  • 服务(或图书馆)彼此独立地发展
  • 代码由单独的团队处理,并在他们自己的周期中发布
  • 您正在将每项服务视为自己的服务 产品

专业人士

  • 构建周期短,导致快速反馈
  • 如果封装得当,repostiories /项目“感觉”更轻盈
  • 鼓励更频繁的发布周期。 这本身很好,但我们发现因为我们经常发布,我们采用了其他良好做法,使发布周期更加顺畅 - 比如使其更顺畅,我们采用了其他良好做法,例如 语义更改日志语义释放
  • 同样,它在版本控制和单独从模块本身发布服务/项目的API时强制实施良好的卫生。 这种摩擦实际上意味着我们花了更多的时间考虑在引入之前是否有变化,这有时会导致更周到的设计选择。
  • 允许以不同的速度发布(和升级)。 如果appA使用LibraryA的v2.3,那么在大量服务中它可以,但appB正在使用v2.5。 使用微回购,这种类型的独立进化变得更加自然。

的利弊

  • 很容易失控,并发现您花费了大量时间来管理跨模块依赖关系和发布周期。
  • 发布后,很难使项目依赖关系保持最新状态。 发布libraryA通常意味着更新serviceB和frameworkC - 有时候还需要进一步发布。 不久,我们处于发布周期的长链中。
  • 如果您确实有交叉回购更改(在接受服务或主要功能时更频繁),那么PR就会分离,并且很难在一个地方查看整个更改集。 这导致审稿人必须掌握更多的记忆知识,我们发现它降低了公关反馈的整体凝聚力

反模式

Microrepos可能不适合您(或者您可能没有正确的分离界限),如果:

  • 您会注意到更改经常跨越多个存储库
  • 依赖管理变得艰难

注意 - 即使我们的微信息库运行良好,我们按功能分组回购,而不是抽象。 这意味着我们的featureX的web代码与服务代码存在于同一个repo中。 这特别有用,我们发现它鼓励整个团队进行更多的全栈开发。

在单回购

Monorepos是所有代码都存在于单个大型存储库中的地方。 它们被谷歌和Facebook着名使用 - 尽管两者最终都必须建立显着的习惯工具来支持这些方法。

考虑使用mono-repos if:

  • 您是一个小团队,或者是在一起发布的单个项目/平台上工作的团队
  • 你是一个项目的新手,还不知道逻辑边界在哪里。 这是相同的论据 Monolith First服务设计。
  • 您的整个平台不断发展并经过一起测试。 即使您单独发布服务,如果这样做,也可以鼓励其他服务逐步升级 - 这在monorepo中尤为有效。

专业人士

  • 总的来说,我发现我们在构建管理上花费的时间要少得多,尽管构建本身需要更长时间
  • 与上述相关,但我们的模块结构更简单 - 不再 BOM 项目,或与父母pom争吵。

的利弊

  • 构建需要更长时间,并随着项目的增长而不断增加。
  • 用于跨CD管道的增量编译的工具不应该在什么位置 - 特别是如果您将容器构建为构建管道的一部分。 (Gradle在这里很好,但在最终的码头工作者建造障碍中偶然发现)
  • 它需要为您的管道提供更多定制的构建逻辑,以支持“只是发布已更改的内容”构建。 我们暂时推迟了这项工作,因此每个版本最终都会部署整个机队,而不是新服务。
  • 跨模块依赖项通常更容易潜入,因此您必须更加依赖依赖性卫生。
  • 我们没有动力实际发布或版本工件 - 因此现在HiP中的所有东西都是 0.1.0 - 快照。 反过来,我们没有看到上面描述的语义提交日志的回报,这意味着我们的提交消息倾向于降低质量。
  • 如果服务不能一起升级,它可能会变得混乱。 什么都不能阻止不同的模块依赖于旧版本的库,但是如果我在浏览代码时,我去探索一个类,只是发现正在使用的代码不是repo中的代码,而是一些较旧的代码,这让人感到困惑。从Maven下来的版本。

反模式

  • 如果您发现对repo中某些文件夹的更改意味着您需要特殊批准(即,您有一个项目所有者需要签署更改),那么请考虑拆分以实现完全存储开发人员的自主权。

总结

一般来说,我发现monorepo的开关(或返回)基本上是积极的。 但是,我们需要投入更多时间来使我们的构建管道变得更加智能,这与我们使用micro-repos管理的复杂性不同。

我发现micro-repos的工作时间最好,就是我们开始使用mono-repo,然后在我们开始感受到构建周期的痛苦时分裂。 然而,分裂是痛苦的,并花了相当多的时间。 我想如果我们使用像这样的工具 越狱 拆分回购,它会快得多。

上面列出的一些优点和缺点仅仅是间接的,并不是单声道与微型回购所必需的。 例如 - 在打破API变化方面考虑周到就像在microorepo上一样可以实现。 但是,我们发现更细粒度的发布周期自然会推动我们独立审阅和发布这些内容。

在单回收中支持微服务的工具仍在不断发展,我怀疑我们会看到更好的解决方案即将到来,但是现在我们承担了较慢构建的成本,作为整体更高速度的功能的权衡。

保存保存

保存保存

我们在网站上使用cookies

如果您接受我们的跟踪cookie,请确认。 您也可以拒绝跟踪,这样您就可以继续访问我们的网站,而无需向第三方服务发送任何数据。
G|translate Your license is inactive or expired, please subscribe again!