大项目的依赖管理

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,所以他们更新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>

他们发现他们有新的错误.不用说,当他们依靠的版本这些缺陷不存在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 中失败。

现在，您可以将测试用例发送给对象池开发人员，并告诉他们在他们通过此测试和其他测试之前您不会升级。这将使他们的生活有点像你的，并且给出足够的测试用例，你的生活最终会更像他们的:-)

如果错误出现在他们的依赖库中，他们将不得不对下游开发人员做同样的事情。