这是一个创建于 1979 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近的工作，有感而发，想请教一下社区的大佬们：
工作的公司目前通过人工收集整理各部门使用的开源软件、中间件及版本，然后通过邮件通知整改一些高危漏洞去推动版本升级，极其低效且不方便统筹管理。
各位所在的公司都是如何管理并推动公司各部门使用的开源软件、中间件版本更新的呢？
 |
1
c4f36e5766583218 2019-06-27 15:52:03 +08:00
pom.xml?
|
 |
2
lazyfighter 2019-06-27 18:49:33 +08:00
你的职级不够
|
 |
3
payton93 OP @lazyfighter 扎心了老哥 但这个事总得要做 还没有想到好的办法
|
 |
4
cnnblike 2019-06-27 20:14:25 +08:00 via iPad
亚马逊有一整个 builder tools team 维护了一个内部的版本管理系统 依赖写在 config 文件里面，有个组会扫描依赖文件然后自动化发邮件的
|
 |
6
Takamine 2019-06-27 23:25:56 +08:00
自建公司内部的 RMS 系统，然后接入云管平台。
|
 |
7
winterbells 2019-06-28 00:40:05 +08:00 via Android
“这几个库版本已经更新到 xxx 了“
”你不要动，一下升级那么多版本，出问题怎么办？“ ㄟ( ▔, ▔ )ㄏ |
|
9
lazyfighter 2019-06-28 11:35:31 +08:00
@payton93 我一般收到的邮件，比如 nginx 暴露的 bug 会导致严重问题，排期 5 天解决，超一天抄送上级主管 m5，超两天 m6,抄三天 m7，超 4 天 m8
|
|
11
cnnblike 2019-06-29 03:38:39 +08:00  1
我建议这样子，用 k8s/docker 接管所有生产环境的构建流程，然后库之类的外部依赖统一走公司内部的 registry，不允许 override。
build 过程中只能访问内部 registry 就可以避免用一些 hacky 的方式拿外部包、库的问题了。 然后强制所有的库依赖都必须在 dependency.xml 或者 package.json 里面写明白。 这样就直接避免了大部分问题。 如果你们已经有内部的 CI/CD 的话，要做的就是 1.写几个包管理器的 wrapper 2.写几个包管理器的配置文件的解析，然后和你们内部的 email 系统 /工单匹配，pre-build 扫描，定期全局扫描，发现问题就发邮件。 ^1. hijack 也好，包管理器 registry 设置也行，其实难度不高的。 |
|
12
cnnblike 2019-06-29 03:49:47 +08:00 1
通过设置内部 registry，我们可以更进一步，在导入开源库之前就对有污染性的开源协议进行评估，如何更好的利用开源产品。
接下去，就是“ never-build-twice ”这个功能的开发，充分利用之前已有的 build 成果。 然后你还可以进一步考虑，怎么进一步接管整个灰盒测试流程啊这种，比方说，只能在线上验证的代码，怎么自动划分一部分给 pre-Prod staging/baking，怎么做 One-Box baking，怎么 lock 住 stage 防止在高峰流量的时候部署？怎么管理运行时环境的环境变量？怎么用这个做服务端 shadowing(保证除了特定流量之外行为和原来完全一致) 反正这一整套 feature 下来，估计你也升职了，我一个 SDE1 就不多嘴了 |
|
13
payton93 OP @c4f36e5766583218 项目的 lib 目录下除开用 maven 的还有一部分是自己封装的 jar 包 这部分咋更新呢 老哥有遇到过这种问题么
|
Select Language