静态网站有什么用,睢宁做网站公司,网站维护公告模板,产品推广介绍怎么写我在本地跑明明成功的#xff0c;为什么在你平台跑就报错#xff1f;用户在 Jenkins 上跑构建时#xff0c;失败了#xff0c;把日志截图给我看#xff0c;如下图#xff1a;在过去几个月#xff0c;每个星期都会有一两个 Jenkins 用户就会给我发送类似的错误日志。这样… 我在本地跑明明成功的为什么在你平台跑就报错用户在 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
