处理拆分为子项目的大型 Ruby 项目的版本控制

Question

TL;DR - 大型项目有许多插件，导致自动化测试经常失败。我想将这个项目拆分为核心存储库和扩展存储库，但如何拆分？

我有一个大型项目（nanoc），其中有大量插件，每个插件都有自己的依赖项。例如：

• 一个

  handlebars

  插件，依赖于

  therubyracer

• HTML 验证器插件，调用外部 Web 服务

很多这些插件偶尔会失败：

• 构建失败（例如

  therubyracer

  或

  nokogiri

  ）；
• 产生nanoc不期望的输出；
• 调用已关闭、限制请求等的 Web 服务（例如 HTML/CSS 验证器）。

nanoc (Travis) 使用的持续集成服务经常报告错误。 95% 的错误是由插件引起的。

这使得持续集成测试结果有些无用。我已经开始忽略“错误”构建状态，只是假设插件出了问题。这显然不是一个好的情况。

我想将项目分为两部分：

• 一个core存储库+gem，包含项目的基本代码，没有插件，以及
• 一个插件存储库+gem，包含每个插件。

我大部分时间都会在 core 上工作，偶尔更新 plugins 存储库，以便它与 core 中完成的工作相匹配（尽管通常，core 中的更改不会影响 plugins）。

这似乎是一个合理的方法，但我有一些保留：

• 我不知道如何处理版本控制。两个宝石是否应该始终使用相同的版本？这可能与我现在使用的语义版本方法发生冲突。
• 是否应该有一个插件存储库，或者每个插件应该有自己的存储库？这可能会使版本控制变得更加困难。
• 我想快速发布新插件，这样人们就不必等待新功能发布才能使用新插件。版本控制在这里更加困难。

感谢想法和想法。

Answer 1

这取决于插件和主应用程序之间的关系。

如果插件只能用于本应用且耦合性较强，则需要将插件放入插件路径并添加到主应用存储库。

如果插件可以用于更通用的目的并且耦合性较低，更好的方法是将这些插件进行 gemify，如下所示：

1. 将它们从主仓库中拉出

2. 为每个 gem 设置单独的存储库

3. 如果您不想公开它们，请在 Gemfile 中使用自定义 gem 路径。*