大項目的依賴管理

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開發人員都是紳士和公平的女士，每當他們發現一個重要的bug時，他們更新所有依賴於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，使他們更新自己的pom.xml使用版本2.0.0.0，現在看起來是這樣的：

<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> 

他們發現他們有新的bug。毋庸置疑，當這些錯誤依賴於的1.9.3.1版本時，這些錯誤並不存在。他們深入到他們的代碼庫的記錄，他們發現，不僅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配置，並將它們全部放入連續性集成服務器中以獲得某種測試失敗情況下的概述。