TL;DR -大規模なプロジェクトには多くのプラグインがあり、自動テストが頻繁に失敗します。このプロジェクトをコア リポジトリと拡張リポジトリに分割したいのですが、どうすればよいですか?
私は、それぞれ独自の依存関係を持つ多数のプラグインを持つ大規模なプロジェクト ( nanoc ) を持っています。例えば:
handlebars
に依存するプラグインtherubyracer
- 外部 Web サービスを呼び出す HTML バリデータ プラグイン
これらのプラグインの多くは時々失敗します:
- ビルドに失敗する (例:
therubyracer
またはnokogiri
); - nanoc が予期しない出力を生成します。
- ダウンしている Web サービス (HTML/CSS バリデーターなど) を呼び出したり、リクエストを調整したりします。
nanoc ( Travis ) が使用する継続的インテグレーション サービスは、非常に定期的にエラーを報告します。これらのエラーの 95% はプラグインが原因です。
これにより、継続的インテグレーション テストの結果が多少役に立たなくなります。「エラー」のビルド ステータスを無視して、プラグインで何か問題が発生したと想定するようになりました。これは明らかに良い状況ではありません。
プロジェクトを 2 つの部分に分割したい:
- プラグインなしで、プロジェクトの基本的なコードを含むコア リポジトリ + gem 、および
- すべての単一のプラグインを含むプラグインリポジトリ + gem。
ほとんどの場合コアで作業し、コアで行われた作業と一致するようにプラグインリポジトリを時々更新します(通常、コアでの変更はプラグインには影響しません)。
これは合理的なアプローチのように思えますが、いくつかの留保があります。
- バージョン管理の方法がよくわかりません。常に両方の gem に同じバージョンを使用する必要がありますか? これは、私が現在使用しているセマンティック バージョンのアプローチと衝突する可能性があります。
- 単一のプラグイン リポジトリが必要ですか、それとも各プラグインが独自のリポジトリを取得する必要がありますか? これにより、バージョン管理がさらに難しくなる可能性があります。
- 人々が新しいプラグインを使用する前に新機能のリリースを待つ必要がないように、新しいプラグインを迅速にリリースしたいと考えています。ここでは、バージョン管理はさらに困難です。
考えやアイデアは高く評価されます。