公司开源软件、中间件版本管理跟进

[payton93]

最近的工作，有感而发，想请教一下社区的大佬们：

工作的公司目前通过人工收集整理各部门使用的开源软件、中间件及版本，然后通过邮件通知整改一些高危漏洞去推动版本升级，极其低效且不方便统筹管理。

各位所在的公司都是如何管理并推动公司各部门使用的开源软件、中间件版本更新的呢？

[c4f36e5766583218]

pom.xml?

[lazyfighter]

你的职级不够

[payton93]

@lazyfighter 扎心了老哥 但这个事总得要做 还没有想到好的办法

[cnnblike]

亚马逊有一整个 builder tools team 维护了一个内部的版本管理系统 依赖写在 config 文件里面，有个组会扫描依赖文件然后自动化发邮件的

[payton93]

@cnnblike 好的多谢多谢 我先去了解这个 看看有没有可操作性

[Takamine]

自建公司内部的 RMS 系统，然后接入云管平台。

[winterbells]

“这几个库版本已经更新到 xxx 了“
”你不要动，一下升级那么多版本，出问题怎么办？“
ㄟ( ▔, ▔ )ㄏ

[payton93]

@Takamine 多谢老哥！了解了下云管平台 挺符合这个需求的 你这边有推荐的产品么

[lazyfighter]

@payton93 我一般收到的邮件，比如 nginx 暴露的 bug 会导致严重问题，排期 5 天解决，超一天抄送上级主管 m5，超两天 m6,抄三天 m7，超 4 天 m8

[Takamine]

@payton93 我对具体外面的服务提供商也不清楚，可能要你自己去排雷了:doge:。

[cnnblike]

我建议这样子，用 k8s/docker 接管所有生产环境的构建流程，然后库之类的外部依赖统一走公司内部的 registry，不允许 override。
build 过程中只能访问内部 registry 就可以避免用一些 hacky 的方式拿外部包、库的问题了。
然后强制所有的库依赖都必须在 dependency.xml 或者 package.json 里面写明白。

这样就直接避免了大部分问题。

如果你们已经有内部的 CI/CD 的话，要做的就是 1.写几个包管理器的 wrapper 2.写几个包管理器的配置文件的解析，然后和你们内部的 email 系统 /工单匹配，pre-build 扫描，定期全局扫描，发现问题就发邮件。

^1. hijack 也好，包管理器 registry 设置也行，其实难度不高的。

[cnnblike]

通过设置内部 registry，我们可以更进一步，在导入开源库之前就对有污染性的开源协议进行评估，如何更好的利用开源产品。
接下去，就是“ never-build-twice ”这个功能的开发，充分利用之前已有的 build 成果。

然后你还可以进一步考虑，怎么进一步接管整个灰盒测试流程啊这种，比方说，只能在线上验证的代码，怎么自动划分一部分给 pre-Prod staging/baking，怎么做 One-Box baking，怎么 lock 住 stage 防止在高峰流量的时候部署？怎么管理运行时环境的环境变量？怎么用这个做服务端 shadowing(保证除了特定流量之外行为和原来完全一致)

反正这一整套 feature 下来，估计你也升职了，我一个 SDE1 就不多嘴了

[payton93]

@c4f36e5766583218 项目的 lib 目录下除开用 maven 的还有一部分是自己封装的 jar 包 这部分咋更新呢 老哥有遇到过这种问题么