CI 流水线的最小可用配置:五个必须改的默认值
依赖缓存命中率从 0 提到 80%,安装阶段通常能省 60-70% 的时间
下面这份配置的目标不是最优,是「半年后回来看还认得」。先把这五项改掉。
先说结论
最小可用配置 = 能启动 + 能观测 + 能备份 + 能回滚。缺一项都不算配好。
- 路径与数据目录先定死,别用默认
- 日志要能看,且要有轮转
- 资源上限显式写出来
- 健康检查与重启策略配好
- 备份 + 回滚演练一次
五项必改
按顺序改,每改一项重启验证一次:
- 数据目录:改到独立分区或卷,避免日志写满根分区
- 监听地址与端口:只监听需要的接口,别 0.0.0.0 全开
- 资源上限:内存、CPU、句柄数显式限制
- 日志:级别、路径、轮转策略三样都写
- 时区:容器与宿主一致,否则日志和定时任务全乱
配置长什么样
依赖缓存命中率从 0 提到 80%,安装阶段通常能省 60-70% 的时间。
| 配置项 | 建议值 | 原因 |
|---|---|---|
| 数据目录 | /builds | 独立分区,便于备份与扩容 |
| 监听 | 127.0.0.1 或内网地址 | 减少暴露面 |
| 内存上限 | 按实测峰值 ×1.3 | 防止 OOM 拖垮宿主 |
| 日志 | 按大小轮转,保留 7-14 天 | 磁盘先满的总是日志 |
| 健康检查 | 30s 间隔,3 次失败重启 | 挂了能自己回来 |
表里的值不是标准答案,是「先按这个来,再按观测调」。
这个服务的几个关键事实
和默认值相关、但文档里往往一笔带过的几条:
- 依赖缓存命中率从 0 提到 80%,安装阶段通常能省 60-70% 的时间
- 测试按文件切成 4 片并行,总时长接近原来的三分之一,不是四分之一
- PR 跑全量、主干只跑增量,是最省机器的一种分工
- 缓存 key 带上锁文件哈希,锁一改就自动失效,比手动清缓存可靠

验证:怎么知道配对了
配完必须验证,不能只看进程在:
- 重启一次,确认能自动起来
- 故意打满内存或断开依赖,看是否按预期降级
- 查看日志,确认时间戳与本机一致
- 跑一次备份,再从备份恢复到一个空目录
配置怎么管
把配置放进版本控制,改动写注释说明原因。半年后你会感谢现在的自己。
还有几处容易忽略的
都是小地方,但出问题时往往就卡在这里。
- CI 时间超过 15 分钟后,开发者开始绕过它,直接在本地合并
- 构建产物不保留,出问题时无法复现当时那一版二进制
- 所有任务串行跑,一次 CI 40 分钟,最后没人等结果
- 缓存 key 用固定字符串,依赖升级后还在用旧缓存
- 失败自动重试三次,把不稳定的测试掩盖成偶发
默认值能用,但只有改过的配置才叫「你的」。
评论 (3)
版本差异要强调,我照着做结果参数名全变了。
最小可用配置这个说法很好,先跑起来再优化。
排查顺序那段直接抄进值班手册了。
发表评论