抛弃业务代码仓库的,gitlab-ci.yml 文件，或者仅保留基本 check build 功能
自己写一个 http 服务接收业务代码仓库的 push 动作 webhook
不同仓库的构建流程在运维平台维护写到数据库里面，运维平台有单独的权限设置
触发了对应的打包在用 trigger 触发 build 仓库的 job ，把构建参数传进去，进行构建，build 仓库仅运维可见

这一套支撑百来个研发十几个技术栈几千个代码仓库还是没问题的

史强 GPT ？

gitlab-ci 吧很方便
可以看看 ACK 托管集群，弹性的幅度很大考虑一下 ASK ，不过这些都是很后期的事情了

长期维护而且没有网络限制的话还是用 web+后台+数据库维护吧，要不然多了肯定乱

gitlab-ci 比较好用，jenkins 刚刚用上的时候很爽，久了各种插件漏洞了、升级冲突了很麻烦

这东西最好由公司的 im 工具提供，分享协作权限什么的都方便

cicd 流程里面用脚本实现一下吧，打完包判断一下依赖的版本，成功后再上传

大方向就是稳定性，效率，成本

访问三方链接没释放，导致集群公网出连接数达到上限
访问白嫖的免费第三方太频繁，导致集群公网出口被对方屏蔽

生产环境部署了某个开源软件使用了官方镜像，写死了镜像 tag:v2.2.0 ，资源紧张 pod 重启后不可用，仔细排查后发现，镜像内的版本变成了 v2.2.1,部分接口参数有变动

换一副新眼睛总得晕乎一两天，哪怕是调整的再好也只能减轻不能消除。
这个问题是镜片的角度和距离发生了变化导致的
如果高精度建模采样能解决这个问题，至少我换眼睛的频率会高很多

天天调接口调，路径依赖了

随便找个星星多的项目，release 里面都会同时提供多个平台的包
amd64 arm64 windows darwin 等等
通过 cicd 解决吧，多编译出来不同环境的二进制包

把几个稍微有点相关的工作放到一起说，当成一件大事说

塞进 docker 里面准备两套启动命令，相同的镜像，不同的端口，不同的持久化目录。
运行第一个启动命令，产生文件，过一段时间之后，停止第一个容器，运行第二个启动命令。这时拷贝第一个产生的文件，重复执行

最近也在想这个问题，能容忍的性能差别越大的服务的单位运行成本肯定是更低的，尤其是云端的弹性环境。
可以通过多个指标判断服务是否需要水平伸缩，cpu 水位 rt 连接数甚至业务上的埋点之类的。

我们这边做法是训练前这一次的数据是确定的，存放在 oss 上，启动的时候有个 initContainer 负责把这个数据拉到一块盘上

业务在发展，会不断的有新服务部署，老服务下线。服务直接的调用关系也在发生变化，有些服务今天可能只有要 0.2 核过几天就要 100 核甚至更多

负载均衡加 k8s 的滚动部署策略

不用 worker 么？
建议 jenkins 本体和打包环境分开，最好虚拟机级别分开，最差也是容器级别隔离
否则打包出问题 cpu 跑满了或者磁盘跑满了整个 jenkins 都不可用