大きなプロジェクトの依存関係管理

Question

私はかなり大きなプロジェクトに取り組んでいます。私たちにはたくさんのプロジェクトがあり、それぞれのプロジェクトには依存関係があります。私たちはMavenを使用しており、通常は問題はありません。だから、多くの詳細を与えることなく、tps-reports、たとえば、特定のプロジェクトのためには、pom.xmlの依存関係セクションがどのように見えることを想像：

<name>TPS-Reports</name> 
    <description> 
    TPS Reports frontend. 
    </description> 
    <dependencies> 
    <dependency> 
    <groupId>com.initech</groupId> 
    <artifactId>gui-components</artifactId> 
    <version>2.5</version> 
    </dependency> 
    <dependency> 
    <groupId>com.initech</groupId> 
    <artifactId>multithreading</artifactId> 
    <version>3.7</version> 
    </dependency> 
    <dependency> 
    <groupId>com.initech</groupId> 
    <artifactId>utils</artifactId> 
    <version>2.3.0.0</version> 
    </dependency> 
    <dependency> 
    <!-- TODO: update to new version --> 
    <groupId>com.initech</groupId> 
    <artifactId>object-pooling</artifactId> 
    <version>1.9.3.1</version> 
    </dependency> 
    </dependencies> 

さて、Initechも依存するプロジェクトのトン、たとえば、object-poolingを、持っています（utilsとmultithreading）のような他の多くのコンポーネントに依存します。

object-poolingの人生は良いです。これはかなり安定したモジュールであり、すべてうまくいきます。他のモジュールと同様に、依存関係もあります。 object-pooling開発者はすべて紳士で公正な女性です。批判的なバグを見つけたら、object-poolingに依存するすべてのプロジェクトを更新します。

1.9.3.1のobject-poolingは安定しており、既知の致命的なバグはありません。開発者は数多くの新機能を追加することが非常に難しく、しばらくしてバージョン2.0.0.0をリリースします。もちろん、1.9.3.1と2.0.0.0との間に中間放出物（例えば、1.9.3.1,1.9.3.2,1.9.4.0,1.9.5.3など）が存在する。私が言ったように、人生は良いですobject-pooling開発者。バージョン2.0.0.0には新機能と多数の修正があります。

しかし、tps-reportsの開発者にとっては、地獄がすぐ近くです。彼らは今かなりの間1.9.3.1を使用しています。このバージョンには既知のバグはありませんので、古いバージョンでは快適です。今、彼らは改造object-poolingを使用したいので、彼らはバージョン2.0.0.0を使用するために彼らのpom.xmlを更新し、それは次のようになります。

<name>TPS-Reports</name> 
    <description> 
    TPS Reports frontend. 
    </description> 
    <dependencies> 
    <dependency> 
    <groupId>com.initech</groupId> 
    <artifactId>gui-components</artifactId> 
    <version>2.5</version> 
    </dependency> 
    <dependency> 
    <groupId>com.initech</groupId> 
    <artifactId>multithreading</artifactId> 
    <version>3.7</version> 
    </dependency> 
    <dependency> 
    <groupId>com.initech</groupId> 
    <artifactId>utils</artifactId> 
    <version>2.3.0.0</version> 
    </dependency> 
    <dependency> 
    <!-- use object poooling's new features --> 
    <groupId>com.initech</groupId> 
    <artifactId>object-pooling</artifactId> 
    <version>2.0.0.0</version> 
    </dependency> 
    </dependencies> 

彼らは、彼らが新しいバグを持っていることを発見します。言うまでもなく、これらのバグは、バージョン1.9.3.1がobject-poolingの場合には存在しませんでした。彼らはコードリポジトリのログを掘り下げて、object-pooling人が何千ものコミットをしたばかりでなく、最新のバージョンのmultithreadingとutilsも使用していることも判明しました。

明らかに、問題が存在する可能性のある場所が数多くあります。それはobject-poolingにあることができ、それはobject-poolingとtps-reportsの間の相互作用になることができ、それはmultithreadingまたはutilsまたは任意の奇妙な組み合わせにすることができます。

質問は次のとおりです。このような問題をどうやって解決しますか？他のプロジェクトに依存する大きなプロジェクトの依存関係をどのように管理しますか？この仕事を手助けするいくつかのツールがありますか？

ありがとうございます！

Answer 1

申し訳ありませんが、シルバーの弾丸はこちらです：ユニットテストは回答です。プロジェクトが大きくなればなるほど、自動テストの重要性は増します。

マニュアルテストでバグが発生したとしても、最終的にはライブラリを使用する特定のケースになります。これをユニットテストに減らすことができます。テストは1.9.3.1に合格し、2.0.0.0で失敗します。

これで、テストケースをオブジェクトプーリング開発者に送信し、このテストやその他のテストに合格するまでアップグレードしていないことを伝えることができます。これであなたの人生はあなたのものと少し変わり、十分なテストケースが与えられれば、あなたの人生は最終的に彼らのようになります:-)

バグが依存ライブラリにあれば、開発者。

Answer 2

私はいくつかのpom設定を使用して、それらをすべてcontinouos統合サーバーに入れて、特定のテストが失敗した状況の概要を取得します。