我在本地跑明明成功的，为什么在你平台跑就报错？
用户在 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管理技术将有效的提升工程质量。
END
对象)
