谈谈软件项目的dependency

说到软件项目的依赖管理，可以从三个方面来考虑：

一、由build system控制的dependency

现在的build system，都支持一定程度上的dependency management， 比如make支持target之间的dependency，ant也支持其每个target之间的dependency（区别是make的每个非PHONY的target是个文件，make会检查输入与输出之间的timestamp来达到incremental build的效果，而ant则是对上一次build没有任何记忆，除了javac task支持incremental compile）

上面的dependency讲的主要是如何确定build的顺序，但dependency管理的另一个非常重要的目标，是自动获取dependency，并设置好：

• 对于C++来讲：includedir(-I), libdir(-L)
• 对于Java来讲：classpath

手工的维护这些path，非常麻烦而且容易出错，因为我们在一个过低的level管理这些信息 - 事实上，正确的做法应该是：用户只需声明我依赖这个component或者我依赖这个library，dependency manager自动帮我设置好这些path。

总的来讲，dependency manager有这么几个作用：

• 让用户在合适的逻辑层次声明dependency，自动设置好需要的path
• Resolve transitive dependency
• Conflict manage （diamond dependency）

这些功能都不是手工能够解决的。

二、不由build system控制的dependency

如果有两个或者多个不同的project，由不同的team开发，甚至使用了不同的build system，那么基本上是不可能把他们放在同一个build pipeline中编译的。但是他们之间又有dependency，该怎么处理？

这里其实就是一个升级的问题， 比如：

B -> A/1.0

而A还是不断的开发，可能会改变已有的实现(引起B的运行时错误），也可能改变已有的接口（引起B的编译时错误），如果B在一段时间之后升级到A的新版本A/1.1，B可能需要很长时间做migration - 或者说integration。其实从continuous integration的角度来理解这个问题，正确的做法应该是：

A要尽可能快的推出一个新的release，而B要立马跟上，这样每次B的改动都非常小，不容易出错，出了错也容易解决。

但推出一个新的release毕竟不是件小事，很多team会有自己的担心：资源不够，risk太高等等 - 所以上述是一个比较理想的情况。在达到那个情况之前，可以另外有个方案：

B继续使用A/1.0, 但是同时B新开出一个branch:B/edge，依赖于最新的A的代码，A的每次build，都会trigger B/edge的build （edge build），这样保证B总是build against最新的A，任何问题都可以在第一时间发现，并fix

关于edge build，值得另外写一篇文章讨论一下。

这里，这种不由build system控制的dependency，就需要由其他系统来控制，比如各种CI server中的job，一个job会trigger另外一个job，也是一种dependency关系，刚好对应起来。

 

三、dependency graph的显示

软件项目之间的dependency graph，很好的反映了各个项目之间的关系，注意这个dependency的单位不是project，而是release，这更动态的反映出了依赖关系，同时，由于你知道每个项目的dependency，根据这个信息就能建出一张完整的dependency graph，从而能得出所有consumer的信息，于是，我就有了关于这个项目的所有dependency和consumer的信息：

• 我用了那些项目，用的版本会不会太老？
• 我被哪些项目用了？受不受欢迎？是不是可以停止支持某个release了（如果没有太多consumer的话）

显示一个项目的dependency时，可以有以下几部分：

• 直接dependency
• 间接dependency
• 直接consumer
• 间接consumer
• dependency graph

关于dependency graph，要注意的是：首先它是一张完整的图，正确的显示了所有直接dependency和间接dependency，但是这样的图，对于一个大的项目来讲的话，会比较乱 - 考虑某个项目即是直接dependency，又是间接dependency的情况，就会有多个箭头指向它。所以一般显示的时候，会将其的transitive reduction显示出来(tred，dot自动做reduction)，在保证其reachbility的同时，减少边的数量，使图看起来比较简练：

 

还有要注意的一点是，我们需要提供额外的metadata，来保证这个图的正确性。以ivy为列，ivy.xml提供了比较完整的dependency信息（没有类似机制的build system至少要产生这种metadata），但其问题是对于有dependency conflict的情况(diamond dependency)，如上面第二张图，如果b和c依赖于不同版本的d，单凭ivy.xml无法确认到底选d的那个版本，这是ant/ivy在build过程当时选择一定的conflict manager方式确定下来的，而这个信息，必须以某种方式告诉dependency graph - 一般的方式就是在build过程中产生metadata并予以保存。

对于没有ivy.xml这种机制的build system，需要产生metadata一保存：

• 所有直接的dependency
• 有conflict的间接dependency

然后可以根据所有项目的这个信息产生正确的dependency graph