这是一个创建于 2302 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近的工作，有感而发，想请教一下社区的大佬们：
工作的公司目前通过人工收集整理各部门使用的开源软件、中间件及版本，然后通过邮件通知整改一些高危漏洞去推动版本升级，极其低效且不方便统筹管理。
各位所在的公司都是如何管理并推动公司各部门使用的开源软件、中间件版本更新的呢？
 | 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 300 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