我在本地跑明明成功的，为什么在你平台跑就报错？
用户在 Jenkins 上跑构建时，失败了，把日志截图给我看，如下图：
在过去几个月，每个星期都会有一两个 Jenkins 用户就会给我发送类似的错误日志。
这样的日志，我通常回：请检查你们的依赖，是不是有依赖没有上传到咱们的 Nexus 仓库。验证方法是先在本地删除你的 .m2 目录，然后再执行一次构建。
当用户业务开发比较急的时候，他们还会说本文标题中的那句话。有些抱怨的意思。我都已经习惯了。
出现这样的情况，我总结大概会有以下原因：
- 用户对于 Maven 这类构建工具不熟悉。
- 用户对于依赖管理不重视，或者没有依赖管理的意识。
- 用户根本不看日志。
面对这三个原因，我就在思考：我们 DevOps 平台能做些什么呢？
我觉得 DevOps 平台是不是可以直截了当地告诉用户：
xxx 依赖在 Nexus 仓库（maven.abc.com）中没有找到，请您先 deploy 该依赖到 Nexus 仓库后，再执行此任务。
如果能检测到缺少的依赖放在哪个代码仓库就更好了。因为这样，就可以提示用户直接到该代码仓库的 deploy 了。
这样的技术，我称为依赖AI管理技术（笑）。当然，这样的技术，应该可以应用于所有的语言。
同时，我们将这些数据（依赖管理失误）统计起来，就可以看出一个团队在依赖管理方面的能力表现了，进而可以有效的对团队进行培训，以提高相应的能力。
回到本文主题，当用户自行检查依赖后，大多数时候，用户就不会来找我了，因为问题已经解决了。可是有一次，用户还是说不行，他已经把 .m2 删除，并把依赖包上传到 Nexus 仓库了。
我检查了他的 pom.xml 文件，发现版本号的定义也是正确的。可是，放在 Jenkins 上执行时，使用的还是旧版本的类的定义。
这就奇怪了。这种情况还是头一回遇到。来来回回检查了好几次，查了好久才知道，是因为用户 deploy 依赖到 Nexus 时，deploy 的是相同的版本号，就是覆盖了原来的版本的包，但是版本没有升级。而 Maven 检测到本地就该版本的依赖，就不会重新下载了。最后，就是大家看到的，本地可以，但是 Jenkins 上就是不行。
最后的解决方式是：
- 用户 deploy 一个新的版本到 Nexus 仓库，并在 pom.xml 中使用新的版本。
- 我们将 Nexus 设置为不允许重复 deploy。
小结
经过这次事件，我们可以看出，依赖管理对于工程质量的重要性。因为，依赖管理不当，很有可能在连开发人员都不知情的情况下引入Bug。
而 DevOps 平台能实现依赖AI管理技术将有效的提升工程质量。
