谈 DevOps 平台实施:我在本地跑明明成功的,为什么在你平台跑就报错?

我在本地跑明明成功的,为什么在你平台跑就报错?

用户在 Jenkins 上跑构建时,失败了,把日志截图给我看,如下图:

谈 DevOps 平台实施:我在本地跑明明成功的,为什么在你平台跑就报错?

在过去几个月,每个星期都会有一两个 Jenkins 用户就会给我发送类似的错误日志。

这样的日志,我通常回:请检查你们的依赖,是不是有依赖没有上传到咱们的 Nexus 仓库。验证方法是先在本地删除你的 .m2 目录,然后再执行一次构建。

当用户业务开发比较急的时候,他们还会说本文标题中的那句话。有些抱怨的意思。我都已经习惯了。

出现这样的情况,我总结大概会有以下原因:

  1. 用户对于 Maven 这类构建工具不熟悉。
  2. 用户对于依赖管理不重视,或者没有依赖管理的意识。
  3. 用户根本不看日志。

面对这三个原因,我就在思考:我们 DevOps 平台能做些什么呢?

我觉得 DevOps 平台是不是可以直截了当地告诉用户:

xxx 依赖在 Nexus 仓库(maven.abc.com)中没有找到,请您先 deploy 该依赖到 Nexus 仓库后,再执行此任务。

如果能检测到缺少的依赖放在哪个代码仓库就更好了。因为这样,就可以提示用户直接到该代码仓库的 deploy 了。

这样的技术,我称为 依赖AI管理技术 (笑)。当然,这样的技术,应该可以应用于所有的语言。

同时,我们将这些数据(依赖管理失误)统计起来,就可以看出一个团队在依赖管理方面的能力表现了,进而可以有效的对团队进行培训,以提高相应的能力。

回到本文主题,当用户自行检查依赖后,大多数时候,用户就不会来找我了,因为问题已经解决了。可是有一次,用户还是说不行,他已经把 .m2 删除,并把依赖包上传到 Nexus 仓库了。

我检查了他的 pom.xml 文件,发现版本号的定义也是正确的。可是,放在 Jenkins 上执行时,使用的还是旧版本的类的定义。

这就奇怪了。这种情况还是头一回遇到。来来回回检查了好几次,查了好久才知道,是因为用户 deploy 依赖到 Nexus 时,deploy 的是相同的版本号,就是覆盖了原来的版本的包,但是版本没有升级。而 Maven 检测到本地就该版本的依赖,就不会重新下载了。最后,就是大家看到的,本地可以,但是 Jenkins 上就是不行。

最后的解决方式是:

  1. 用户 deploy 一个新的版本到 Nexus 仓库,并在 pom.xml 中使用新的版本。
  2. 我们将 Nexus 设置为不允许重复 deploy。

小结

经过这次事件,我们可以看出,依赖管理对于工程质量的重要性。因为,依赖管理不当,很有可能在连开发人员都不知情的情况下引入Bug。

而 DevOps 平台能实现 依赖AI管理技术 将有效的提升工程质量。

原文 

https://showme.codes/2019-11-11/devops-platform-dependency-manage/

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 谈 DevOps 平台实施:我在本地跑明明成功的,为什么在你平台跑就报错?

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址