构建加速

概述 你大概率遇到过这种场景：开发提交一行代码，CI 跑了 40 分钟，CD 部署又磨了 20 分钟。等你喝完两杯咖啡回来一看——构建失败，得重新来。一天下来，光等流水线就耗掉 3 个小时。 这不是个例。我接触过的团队里，流水线超过 30 分钟的占多数。DORA 报告的数据更直接：高效团队的部署频率是低效团队的 973 倍，而流水线耗时是最核心的分水岭——前者平均 5 分钟内完成一次部署，后者要 1 小时以上。 我自己踩过这个坑。在某出行项目里，团队有一条 Go 微服务流水线，从代码提交到生产部署端到端 90 分钟。开发同学天天吐槽，发布日更是鸡飞狗跳。后来我们花了两周时间做全链路优化，把 90 分钟压到 5 分钟。这篇文章就是把那次优化的思路、方法和踩过的坑写下来，让你拿来就能用。 核心优化方向就四个：构建缓存、并行调度、镜像分层、增量发布。下面逐个拆解。 流水线慢在哪：先做性能画像，别盲猜 很多人一上来就改配置，今天加个缓存，明天搞个并行。结果改了两周，流水线还是 40 分钟——因为你不知道时间花在哪了。 正确的做法是先做性能画像（Profiling），把流水线每个阶段的耗时精确到秒，找出真正的瓶颈。 分阶段耗时分析 一条典型的微服务 CI/CD 流水线包含这些阶段： 阶段 优化前耗时 占比 常见瓶颈 代码拉取 1-3 min 3% 全量克隆、大仓库 LFS 文件 依赖安装 8-15 min 17% 无缓存、全量下载、锁文件解析慢 代码编译 10-20 min 22% 无增量编译、串行编译多模块 单元测试 10-20 min 22% 串行执行、测试初始化慢、无并行 镜像构建 5-15 min 12% 无分层缓存、全量重建 镜像推送 3-8 min 6% 大镜像、无压缩、网络瓶颈 部署发布 10-30 min 18% 滚动更新慢、无健康检查优化 这是我实际测量过的数据。依赖安装 + 代码编译 + 单元测试三项加起来占了 60% 以上。这就是你要重点啃的硬骨头。...