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

Question

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

我有一个大项目（nanoc），它有很多插件，每个插件都有自己的依赖项。例如：

• handlebars插件，取决于therubyracer
• 一个HTML验证器插件，它调用外部Web服务

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

• 无法构建（例如therubyracer或nokogiri）;
• 产生nanoc不期望的输出;
• 调用已关闭的Web服务（例如HTML / CSS验证程序），限制请求等

nanoc使用的持续集成服务（Travis）会定期报告错误。 95％的错误是由插件引起的。

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

我想将项目分为两部分：

• 核心存储库+ gem，包含项目的基本代码，没有插件，
• 包含每个插件的插件存储库+ gem。

我会在大多数情况下处理核心，偶尔会更新插件存储库，以便它与 core 中完成的工作相匹配（尽管通常， core 中的更改不会影响插件）。

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

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

赞赏我们的想法和想法。

Answer 1

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

如果插件只能用于此应用并且存在强耦合，则需要将插件放入插件路径并将其添加到主应用程序存储库。

如果插件可以用于更多通用目的并且耦合较少，那么更好的方法是将这些插件安抚如下：

1. 将它们从主回购中取出

2. 为每个宝石设置单独的回购

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