企业官网建设流程全解析

开篇：一次"合并周"

一个 6 人的游戏项目组，做一个新版本。

大家分头开工，各开各的分支：

张三 → feature/新战斗系统 （改了 87 个文件） 李四 → feature/公会玩法 （改了 64 个文件） 王五 → feature/新手引导重做 （改了 31 个文件） 赵六 → feature/UI框架升级 ★（改了 212 个文件） 钱七 → feature/服务器协议重构 ★（改了 105 个文件） 孙八 → feature/商城 （改了 43 个文件）

三周后，说好的"合并日"到了。

合并日当天

09:00 张三先合。顺利，10 分钟搞定 09:20 李四合。和张三冲突 6 个文件，花了 40 分钟 10:30 王五合。冲突 14 个文件。开始需要叫人一起看 14:00 赵六合 UI 框架升级 ↓ 和前面三个人全都冲突 因为他重命名了 40 多个基类 ↓ 前面三个人的代码全部编译不过

┌──────────────────────────────────────────────┐ │ 15:30 项目第一次编译失败 │ │ 16:00 张三、李四、王五被叫回来一起改 │ │ 18:00 勉强编译通过了 │ │ 18:10 启动游戏 —— 点"开始"直接崩溃 │ │ 没人知道是谁的问题 │ └──────────────────────────────────────────────┘

接下来的五天

Day 1 查崩溃。最后发现是钱七改了协议字段， 但李四的公会玩法还在用旧字段 Day 2 修好了。又发现新手引导跑不通， 因为赵六的 UI 框架把某个接口改了名 Day 3 修好了。战斗数值全乱， 查了一天发现是两个人各自改了同一份配置表 Day 4 修好了。开始回归测试，发现一堆之前好好的功能坏了 Day 5 终于能跑了

┌──────────────────────────────────────────────┐ │ 6 个人 × 5 天 = 30 人日 │ │ 全部花在"让代码能一起跑"上 │ │ 一行新功能都没写 │ └──────────────────────────────────────────────┘

复盘会上，主程说了一句话：

“问题不是我们代码写得烂。
问题是我们让这些代码分开跑了三周。”

第一部分：先理解"集成"这两个字

一、集成 = 把大家的代码合到一起，并且让它真的能跑

很多人卡在"集成"这个词上，觉得它很抽象。其实它就是两件事：

① 合并代码 （git merge） ② 确认合完之后还能正常工作 （能编译、能跑、功能没坏）

第 ② 件事才是重点。

代码合进去不难，git merge一下就行。难的是——合进去之后，它还是不是一个能用的东西？

二、为什么"分开越久，合并越痛"

这里有个关键的直觉：合并的代价不是线性增长的，是指数增长的。

两个人分开写代码 ↓ 就像两条从同一点出发、慢慢分叉的路 分开 1 天 → 两条路差一点点，走回去很容易 ┌─ ─────┤ └─ 分开 1 周 → 差距明显了 ┌─────── ─────┤ └─────── 分开 3 周 → 已经是两个不同的地方了 ┌────────────────────── ─────┤ └──────────────────────

更糟的是，人不止两个。

2 个人合并 → 1 对组合 6 个人合并 → 15 对组合 ↓ 每一对都可能冲突 而且 A 和 B 合完之后的结果， 可能又和 C 冲突（这是第二轮冲突）

三、还有更隐蔽的一种冲突

Git 会告诉你"这两行代码冲突了"，你能看见。

但有一类冲突，Git 完全看不出来：

张三写的： 一个函数 getPlayerLevel()，返回 int 钱七写的： 把 Player 类的 level 字段改成了字符串 ↓ 两个人改的是不同文件 ↓ Git 说：没有冲突，合并成功 ✓ ↓ 编译不过 / 或者编译过了但运行时崩溃

┌──────────────────────────────────────────────┐ │ 这叫"语义冲突"（Semantic Conflict） │ │ │ │ 文本上不冲突，逻辑上冲突 │ │ ↓ │ │ ★ 只有真的编译一次、跑一次，才能发现 │ └──────────────────────────────────────────────┘

这就是为什么"合并"不等于"集成"。
合并只是把文字拼在一起，集成是要确认拼出来的东西还能用。

第二部分：CI 是什么

四、把名字拆开看

Continuous Integration 持续 集成 ↓ ↓ 一直在做 合代码 + 确认能跑

合起来的意思就是：

不要攒着，每天（甚至每小时）都把代码合到一起，
并且每次合完都立刻自动验证一遍能不能跑。

五、一个最笨但最准确的比喻

没有 CI = 攒一个月的碗，月底一次性洗 ↓ 堆成山、发霉、粘在一起、洗一整天 有 CI = 每顿饭后立刻洗 ↓ 每次 3 分钟，永远不会堆积

注意重点：洗碗的总量没变，但总耗时差了十倍。

因为攒起来之后，你多出来的工作是：
把粘在一起的碗分开、刮掉干掉的污渍、重新排序。
这些工作，当天洗根本不存在。

代码合并一模一样。

六、CI 每次具体干三件事

┌──────────────────────────────────────────────┐ │ 你 push 了一次代码 │ │ ↓ │ │ ① 拉取最新主干 + 合并你的改动 │ │ ↓ │ │ ② 构建（编译 / 打包） │ │ → 编译不过？立刻停，告诉你 │ │ ↓ │ │ ③ 验证（跑测试 / 代码检查） │ │ → 测试挂了？立刻停，告诉你 │ │ ↓ │ │ ④ 全绿 → 通知"没问题" │ │ 任何一步红 → 5 分钟内 @ 你 │ └──────────────────────────────────────────────┘

就这么简单。CI 的本质就是一个"自动化的看门人"。

七、澄清一个巨大的误解

❌ “我们买了 Jenkins / 用了 GitHub Actions，所以我们有 CI 了。”

这是最普遍的错误认知。

CI 首先是一种【工作方式】 ↓ 工具只是用来支撑这种工作方式的

判断你到底有没有在做 CI，只看一个问题：

你的团队成员，平均多久把自己的代码合进主干一次？

每天至少一次 → ✅ 这是 CI 三五天一次 → ⚠️ 勉强算 一两周一次 → ❌ 你只是有个构建服务器 只在版本末期合 → ❌ 那叫"集成地狱"，和 CI 相反

┌──────────────────────────────────────────────┐ │ 一个团队可以： │ │ 有 Jenkins，但没有 CI │ │ （因为大家还是开长期分支，月底才合） │ │ │ │ 没有 Jenkins，但有 CI │ │ （每天合，合完手动编译跑一遍，也算） │ │ ↓ │ │ 当然，有工具会让这件事轻松一百倍 │ └──────────────────────────────────────────────┘

第三部分：为什么都在用

八、价值一：把"找 bug"变成"找不到都难"

这是 CI 最大、但最少被说清楚的价值。

想象你在草堆里找针

场景 A：没有 CI 三周攒了 2000 次提交，一次性合并 ↓ 发现有个 bug ↓ 嫌疑范围：2000 次提交、6 个人、几万行改动 ↓ ★ 排查成本：几小时到几天

场景 B：有 CI 每次提交都自动验证 ↓ 第 1487 次提交时，CI 亮红灯 ↓ 嫌疑范围：★ 就是这一次提交，通常几十行 ↓ ★ 排查成本：几分钟

┌──────────────────────────────────────────────┐ │ CI 的核心魔法： │ │ │ │ 把"出错了"和"是哪行出的错" │ │ 这两件事的距离，压缩到最小 │ │ │ │ 不是它更会找 bug │ │ 是它让 bug 藏不住 │ └──────────────────────────────────────────────┘

一个数字：bug 发现得越晚，修复成本越高

发现时机 相对修复成本 ────────────────────────────── 写代码时 1x CI 上（几分钟后） ~2x QA 测试时 ~10x 上线后 ~50x+

为什么差这么多？

写代码时发现 → 你脑子里还记得这段逻辑，改 2 分钟 上线后发现 → 你已经忘了这段代码 → 要先复现问题 → 要定位是哪次改动引入的 → 要评估影响范围 → 要紧急发版 → 要通知用户、可能要补偿

CI 做的事，就是把所有问题尽可能往左推。

九、价值二：主干永远是"能用的"

没有 CI 的项目，主干是薛定谔的：

"现在的主干能跑吗？" "不知道，你自己拉下来试试"

这句话带来的连锁反应：

主干状态不确定 ↓ 新人拉代码，编译不过，卡半天 ← 入职第一天就被劝退 ↓ 策划想看个功能，拉不到能跑的包 ↓ QA 不知道该测哪个版本 ↓ 要演示了，临时抓一个"应该能跑"的版本，现场崩溃

有 CI 之后：

主干上每一次提交都被验证过 ↓ ★ "主干随时可构建、可运行"变成一个可以依赖的承诺 ↓ 任何人、任何时候拉主干，都能跑起来

这个承诺的价值，比很多人想的大得多——
它是"随时能出包"的前提，而"随时能出包"是快速迭代的前提。

十、价值三：把"人肉规矩"变成"机器规矩"

每个团队都有一堆口头约定：

"提交前记得跑一下编译" "记得跑单元测试" "代码风格要统一" "不要提交 .meta 冲突的文件" "不要把调试代码提交上去"

这些约定的共同问题：靠自觉，而自觉会失效。

赶进度的时候会忘 新人不知道有这规矩 老人觉得"我这次改动很小，不用测"

CI 把这些变成硬性检查：

┌──────────────────────────────────────────────┐ │ CI 流水线里加一步： │ │ 代码风格检查不过 → 直接红灯，合不进去 │ │ ↓ │ │ 规矩从"希望你遵守" │ │ 变成"你不遵守就进不来" │ └──────────────────────────────────────────────┘

而且它不会疲劳、不会给面子、不会因为你是主程就放行。

十一、价值四：敢重构了

这是个容易被忽略的心理层面的价值。

没有测试和 CI 的项目 ↓ "这段代码写得很烂，但我不敢改" "改了万一哪里坏了，我不知道" ↓ 屎山越堆越高

有 CI + 测试覆盖 ↓ "我改一下，CI 会告诉我有没有坏" ↓ ★ 敢改了 ↓ 代码质量能持续改善，而不是单向腐化

第四部分：一条 CI 流水线长什么样

十二、完整流程

┌──────────────────────────────────────────────────────┐ │ 开发者 │ │ git push / 提 Pull Request │ └───────────────────┬──────────────────────────────────┘ ↓ webhook 触发 ┌──────────────────────────────────────────────────────┐ │ ① 准备环境（1~2 分钟） │ │ · 分配一台干净的机器 / 容器 │ │ · 拉代码（含子模块、LFS 大文件） │ │ · 恢复缓存（依赖包、编译中间产物） │ └───────────────────┬──────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────┐ │ ② 静态检查（30 秒 ~ 2 分钟）★ 最快，放最前面 │ │ · 代码风格（lint / format） │ │ · 静态分析（找明显的空指针、死代码） │ │ · 敏感信息扫描（有没有把密钥提交上来）★ │ │ · 依赖漏洞扫描 │ └───────────────────┬──────────────────────────────────┘ ↓ 通过 ┌──────────────────────────────────────────────────────┐ │ ③ 构建（2~30 分钟，看项目） │ │ · 编译 │ │ · 打包 │ │ ★ 这一步失败最常见，也最致命 │ └───────────────────┬──────────────────────────────────┘ ↓ 通过 ┌──────────────────────────────────────────────────────┐ │ ④ 单元测试（1~10 分钟） │ │ · 测单个函数/类的逻辑 │ │ · 不依赖数据库、网络 │ │ · 应该很快 │ └───────────────────┬──────────────────────────────────┘ ↓ 通过 ┌──────────────────────────────────────────────────────┐ │ ⑤ 集成测试（5~30 分钟） │ │ · 起数据库、起服务，测模块之间的协作 │ │ · 慢，可以只在合主干时跑 │ └───────────────────┬──────────────────────────────────┘ ↓ 通过 ┌──────────────────────────────────────────────────────┐ │ ⑥ 产出物（Artifact） │ │ · 保存构建出来的包 │ │ · 上传到内部分发平台 / TestFlight / 测试服 │ └───────────────────┬──────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────┐ │ ⑦ 通知 │ │ · 企业微信 / Slack / 钉钉 │ │ · ★ 失败必须 @ 到具体的人，不能只发群里 │ └──────────────────────────────────────────────────────┘

十三、顺序的讲究：快的放前面

┌──────────────────────────────────────────────┐ │ 为什么静态检查要放在编译前面？ │ │ │ │ 因为它只要 30 秒 │ │ 而编译要 10 分钟 │ │ ↓ │ │ 如果你只是少了个分号、格式没对齐 │ │ 30 秒就能告诉你，不用等 10 分钟 │ └──────────────────────────────────────────────┘

这叫「快速失败」（Fail Fast） 原则：越便宜的检查，越靠前 越可能失败的检查，越靠前

第五部分：实际配置长什么样

十四、一个最小的 CI（10 行）

别被吓到，CI 可以很简单。这是一个后端 Java 项目的最小配置：

# .github/workflows/ci.ymlname:CIon:[push,pull_request]# 每次推代码、每次提 PR 都跑jobs:build:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4# 拉代码-uses:actions/setup-java@v4# 装 JDKwith:{java-version:'17',distribution:'temurin'}-run:mvn-B verify# 编译 + 跑测试

就这样。你已经有 CI 了。

它会做的事：

• 每次有人 push，自动拉代码、编译、跑测试
• 失败时在 GitHub 上打个红叉，PR 页面会显示"检查未通过"

十五、一个完整一些的例子

name:CIon:push:branches:[main,develop]pull_request:branches:[main,develop]# ★ 同一个分支有新提交时，取消上一次还在跑的concurrency:group:${{github.workflow}}-${{github.ref}}cancel-in-progress:truejobs:# ═══════ 阶段一：快速检查（并行，1~2 分钟）═══════lint:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-uses:actions/setup-node@v4with:{node-version:'20',cache:'npm'}-run:npm ci-run:npm run lint# 代码风格-run:npm run typecheck# 类型检查secret-scan:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4with:{fetch-depth:0}-name:扫描是否误提交了密钥uses:gitleaks/gitleaks-action@v2# ═══════ 阶段二：测试 ═══════test:needs:[lint]# ★ lint 过了才跑runs-on:ubuntu-latestservices:# CI 里临时起的依赖postgres:image:postgres:16env:POSTGRES_PASSWORD:testoptions:>---health-cmd pg_isready--health-interval 10s--health-retries 5redis:image:redis:7steps:-uses:actions/checkout@v4-uses:actions/setup-node@v4with:{node-version:'20',cache:'npm'}-run:npm ci-run:npm run test:unit-run:npm run test:integrationenv:DATABASE_URL:postgres://postgres:test@localhost:5432/testREDIS_URL:redis://localhost:6379-name:上传测试报告if:always()# ★ 失败时也要上传uses:actions/upload-artifact@v4with:name:test-reportpath:coverage/# ═══════ 阶段三：构建 ═══════build:needs:[test,secret-scan]runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-uses:actions/setup-node@v4with:{node-version:'20',cache:'npm'}-run:npm ci-run:npm run build-name:保存构建产物uses:actions/upload-artifact@v4with:name:dist-${{github.sha}}path:dist/retention-days:7# ═══════ 通知 ═══════notify:needs:[build]if:failure()# ★ 只在失败时通知runs-on:ubuntu-lateststeps:-name:通知到群run:|curl -s -X POST "${{ secrets.WEBHOOK }}" \ -H 'Content-Type: application/json' \ -d '{ "msgtype": "text", "text": { "content": "❌ CI 失败\n分支: ${{ github.ref_name }}\n提交者: ${{ github.actor }}\n链接: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}", "mentioned_list": ["${{ github.actor }}"] } }'

十六、游戏项目的 CI 有什么不一样

因为前面几篇都在聊游戏，这里单独说一下。

┌──────────────────────────────────────────────────────┐ │ 游戏项目做 CI 的三个特殊困难 │ ├──────────────────────────────────────────────────────┤ │ ① 资源巨大 │ │ 美术资源几十上百 GB，拉一次代码就要很久 │ │ → 必须用 Git LFS，并且做好缓存 │ ├──────────────────────────────────────────────────────┤ │ ② 构建极慢 │ │ Unity 打一个 iOS 包可能要 40 分钟起 │ │ → 必须分层：不是每次提交都打完整包 │ ├──────────────────────────────────────────────────────┤ │ ③ 需要特定机器 │ │ iOS 必须用 Mac，而 Mac 构建机很贵 │ │ → 通常用自建 Mac mini 做 self-hosted runner │ ├──────────────────────────────────────────────────────┤ │ ④ 单元测试难写 │ │ 大量逻辑和引擎、表现耦合 │ │ → 先从"能编译"开始，别一上来就追求测试覆盖率 │ └──────────────────────────────────────────────────────┘

分层策略（关键）

┌──────────────────────────────────────────────────────┐ │ 每次提交（要快，5 分钟内） │ │ · 代码风格检查 │ │ · 编译 Editor（★ 不打包，只验证能不能编译） │ │ · 跑纯逻辑的单元测试 │ │ · 检查资源命名规范、是否有超大贴图 │ ├──────────────────────────────────────────────────────┤ │ 合并到 develop（可以慢一点，30 分钟） │ │ · 完整编译 │ │ · 打一个 Android 测试包 │ │ · 跑集成测试 │ ├──────────────────────────────────────────────────────┤ │ 每晚定时（Nightly，可以很慢，2 小时） │ │ · 打 iOS + Android 完整包 │ │ · 上传 TestFlight / 内部分发 │ │ · 跑自动化冒烟测试（启动、进主城、打一关） │ │ · 性能基线检查（包体大小、启动耗时、内存峰值） │ └──────────────────────────────────────────────────────┘

★ 核心原则： 开发者每次提交要等的时间，必须短到他愿意等 慢的东西全部推到"合并时"和"每晚"

第六部分：CI 和 CD 的关系

十七、三个词的区别

这三个词经常被混着说，但含义不同：

┌──────────────────────────────────────────────────────┐ │ CI 持续集成 Continuous Integration │ │ 频繁合代码 + 自动验证能不能跑 │ │ 终点：产出一个"验证过的包" │ ├──────────────────────────────────────────────────────┤ │ CD 持续交付 Continuous Delivery │ │ 在 CI 基础上，自动把包部署到测试/预发环境 │ │ ★ 随时可以上线，但上不上线由人决定 │ │ 终点：一个"随时能上线的包"躺在那，等人点按钮 │ ├──────────────────────────────────────────────────────┤ │ CD 持续部署 Continuous Deployment │ │ 比上面更进一步：连按钮都不用点 │ │ 验证全过 → 自动上生产 │ │ 终点：代码合并后几分钟，用户就用上了 │ └──────────────────────────────────────────────────────┘

代码提交 ↓ [═══ CI ═══] 编译 + 测试 + 产包 ↓ [═ 持续交付 ═] 自动部署到测试环境、预发环境 ↓ ★ 人工审批 ←── 持续交付停在这 ↓ [═ 持续部署 ═] 自动上生产 ←── 持续部署不停

十八、该做到哪一步

┌──────────────────────────────────────────────────────┐ │ 几乎所有团队都应该做 CI │ │ 成本低，收益立竿见影 │ ├──────────────────────────────────────────────────────┤ │ 大部分团队应该做到"持续交付" │ │ 能自动部署到测试环境就很够用了 │ ├──────────────────────────────────────────────────────┤ │ "持续部署"看业务性质 │ │ Web 服务 / 后端 API → 很适合 │ │ 移动 App → ★ 做不到，要过应用商店审核 │ │ 游戏客户端 → 不适合，版本要配合运营节奏 │ │ 金融/医疗 → 通常有合规要求，需人工审批 │ └──────────────────────────────────────────────────────┘

所以对游戏团队来说，通常是：

CI（必做） + 自动出包分发到测试渠道（持续交付） + 正式发版还是人工控制

第七部分：从零开始怎么落地

十九、四个阶段，别想一步到位

阶段 1：先让它跑起来（第 1 周）

目标：每次 push，自动编译一次 编译失败，群里有通知 不需要：单元测试、覆盖率、复杂流水线

┌──────────────────────────────────────────────┐ │ ★ 这一步的价值已经很大了 │ │ │ │ "主干编译不过"这个问题 │ │ 在很多团队占了所有集成问题的一半以上 │ └──────────────────────────────────────────────┘

阶段 2：加上最基本的验证（第 2~4 周）

□ 代码风格检查（lint） □ 密钥泄露扫描（★ 强烈建议，成本极低收益极大） □ 给核心的纯逻辑模块补几个单元测试 （不要追覆盖率，先挑最容易出错、最重要的写）

阶段 3：改变工作方式（第 2~3 个月）★ 最难的一步

这一步不是技术问题，是习惯问题。

□ 分支存活时间 ≤ 2 天 （不是"不许开分支"，是"开了就快点合回去"） □ 每个人每天至少合一次主干 □ 主干保护： · 必须通过 CI 才能合并 · 必须至少一人 review □ ★ 建立"红灯停"规则 CI 红了，全组优先修它，不合新代码

"红灯停"是 CI 能不能活下来的分水岭。

如果 CI 红了大家照常提交 ↓ 红灯会一直红下去 ↓ 大家开始习惯性忽略红灯 ↓ ★ CI 就死了 —— 它还在跑，但没人看了

这是 CI 最常见的死法。不是被关掉，是被无视。

阶段 4：优化和扩展（持续）

□ 优化构建速度（缓存、并行、增量） □ 加集成测试、自动化冒烟测试 □ 自动出包分发（TestFlight / 蒲公英 / 内部平台） □ 加性能基线检查 □ 数据化：统计失败率、平均修复时间

二十、工具怎么选

★ 选择建议： 代码托管在哪，就先用哪家自带的 别一上来就自建 Jenkins —— 维护成本比你想的高

关于构建机：

云上托管的 runner ✓ 省事，不用维护 ✗ 大项目慢（每次都是干净环境，缓存要重下） ✗ iOS/Mac 机器贵 自建 runner（self-hosted） ✓ 快（本地缓存、本地资源） ✓ 游戏项目基本必须自建（Unity 授权、Mac 机器） ✗ 要自己维护、要保证环境一致

第八部分：构建速度是生死线

二十一、为什么速度这么重要

CI 跑一次要 5 分钟 ↓ 开发者：提交完喝口水就好了 → 愿意频繁提交 ✓ CI 跑一次要 40 分钟 ↓ 开发者：提交一次要等大半天，那我攒一攒再提 ↓ ★ 回到了"攒着不合"的老路 ↓ CI 名存实亡

┌──────────────────────────────────────────────┐ │ CI 的速度直接决定了大家的提交频率 │ │ 而提交频率就是 CI 的全部价值所在 │ │ ↓ │ │ 慢的 CI 会自己把自己杀死 │ └──────────────────────────────────────────────┘

一个参考线：

理想： < 5 分钟 （开发者会等着看结果） 可接受：< 10 分钟 （去做点别的，回来看） 危险： > 20 分钟 （开始有人绕过它）

二十二、加速的几个办法

┌──────────────────────────────────────────────────────┐ │ ① 缓存依赖 │ │ npm / maven / gradle / NuGet 包缓存 │ │ Unity 的 Library 目录缓存 │ │ ★ 最容易见效的一招，经常能省一半时间 │ ├──────────────────────────────────────────────────────┤ │ ② 并行 │ │ lint、单测、类型检查同时跑，不排队 │ ├──────────────────────────────────────────────────────┤ │ ③ 分层（前面讲过的） │ │ 快的每次跑，慢的只在合并时跑，最慢的每晚跑 │ ├──────────────────────────────────────────────────────┤ │ ④ 只跑受影响的部分 │ │ 改了哪个模块，就只测哪个模块 │ │ （大仓库 / monorepo 必备） │ ├──────────────────────────────────────────────────────┤ │ ⑤ 自动取消过期任务 │ │ 同一分支连续推三次，前两次直接取消 │ │ （前面配置里的 cancel-in-progress） │ ├──────────────────────────────────────────────────────┤ │ ⑥ 更好的机器 │ │ ★ 最简单粗暴但最有效的一招 │ │ 一台构建机的钱 vs 10 个人每天多等 20 分钟 │ │ 算一下就知道哪个贵 │ └──────────────────────────────────────────────────────┘

第九部分：怎么知道 CI 做得好不好

二十三、四个关键指标

┌──────────────────────────────────────────────────────┐ │ ① 主干构建成功率 │ │ 目标：> 90% │ │ 太低 → 说明大家提交前根本没自测 │ │ ⚠️ 但也不能是 100%（100% 说明 CI 检查得太松） │ ├──────────────────────────────────────────────────────┤ │ ② ★ 平均修复时间（红灯持续多久） │ │ 目标：< 30 分钟 │ │ 这是最能反映团队 CI 文化的指标 │ │ 红灯挂一整天 = 没人把它当回事 │ ├──────────────────────────────────────────────────────┤ │ ③ 流水线时长 │ │ 目标：主流水线 < 10 分钟 │ │ 超过 20 分钟就要专门花时间优化 │ ├──────────────────────────────────────────────────────┤ │ ④ ★ 人均每日合并次数 │ │ 目标：≥ 1 次/人/天 │ │ 这个数字直接反映"你到底有没有在做 CI" │ └──────────────────────────────────────────────────────┘

二十四、一个容易被忽略的健康指标

「不稳定测试」（Flaky Test）的比例 = 同样的代码，有时过有时不过的测试

┌──────────────────────────────────────────────┐ │ 不稳定测试是 CI 的慢性毒药 │ │ │ │ 第 1 次红灯 → 重跑一下，绿了 → "哦，误报" │ │ 第 5 次红灯 → 直接重跑，都不看 │ │ 第 20 次 → ★ 真的挂了也以为是误报 │ │ ↓ │ │ CI 失去了可信度，等于没有 │ └──────────────────────────────────────────────┘

处理原则： 发现不稳定测试 → 立刻修，或者立刻标记跳过 ★ 绝不允许"重跑一下就好了"成为常态

第十部分：坑表

速查表

一句话定义

CI = 每天（至少）把代码合进主干一次 + 每次合并都自动验证一遍能不能跑 + 一旦失败立刻修

判断你有没有在做 CI

只问一个问题： ★ 团队成员平均多久合一次主干？ 每天 ≥ 1 次 → ✅ 是 CI 一周一次 → ❌ 只是有个构建服务器 版本末期才合 → ❌ 集成地狱

CI 每次做的三件事

① 拉最新代码 + 合并 ② 构建（能不能编译） ③ 验证（测试 / 检查） → 任何一步失败，立刻通知具体的人

流水线顺序（快的在前）

静态检查（30s）→ 构建（5m）→ 单测（3m）→ 集成测试（15m）→ 产包

四条铁律

① 频繁合并 分支寿命 ≤ 2 天 ② 每次提交都跑 不是每天跑一次 ③ 快 主流水线 < 10 分钟 ④ ★ 红灯停 CI 红了，全组优先修

四个指标

主干构建成功率 > 90% ★ 平均修复时间 < 30 分钟 流水线时长 < 10 分钟 ★ 人均日合并次数 ≥ 1 次

CI / 持续交付 / 持续部署

CI 合代码 + 验证 → 产出一个验证过的包 持续交付 + 自动部署测试环境 → 随时能上线，等人点按钮 持续部署 + 自动上生产 → 合并后几分钟用户就用上了 移动 App / 游戏客户端：做到"持续交付"即可， 正式发版必须人工控制

落地四阶段

① 第 1 周 push → 自动编译 → 失败通知 （就这么简单） ② 第 2~4 周 + lint + 密钥扫描 + 核心单测 ③ 第 2~3 月 ★ 改工作方式：短分支 + 每天合 + 红灯停 ④ 持续 优化速度、加自动化测试、自动出包

游戏项目分层策略

每次提交 代码检查 + 编译验证 + 纯逻辑单测 （< 5 分钟） 合主干 完整编译 + 打 Android 测试包 （< 30 分钟） 每晚定时 双平台打包 + 上传分发 + 冒烟测试 + 性能基线

加速六招

缓存依赖 / 并行任务 / 分层触发 / 只测受影响模块 / 取消过期任务 / ★ 换更好的机器

结语：三个反直觉的真相

一、CI 里最重要的字，是"持续"，不是"集成"。

大部分团队理解 CI 的方式是：“搭一套自动构建系统”。
于是他们买了服务器、写了流水线、配好了通知，
然后继续开着两周一合的长期分支。

结果： 每次合并，CI 就亮起一大片红灯 因为一次性合进来几百个改动 谁都不知道是哪个引起的 ↓ CI 从"帮手"变成了"每次合并都要过的一道坎" ↓ 大家开始讨厌它

CI 真正的那个"技巧"，简单到让人不敢相信：把批次改小。

一次合 500 行，出问题要在 500 行里找。
一次合 50 行，出问题只在 50 行里找。
而你合 10 次 50 行，总量是一样的，总痛苦却小一个数量级。

工具只是让"合 10 次"这件事变得不费力而已。
没有改变合并频率，就没有做 CI。

二、CI 的产出不是"更少的 bug"，是"更便宜的 bug"。

这是个经常让人失望的真相：
上了 CI，你的 bug 数量不会明显减少。

人还是那些人，代码还是那个水平，该写错的还是会写错。

CI 改变的是 bug 的成本结构：

没有 CI bug 在两周后被发现 嫌疑范围：几千行、6 个人的改动 排查：1 天 修复时你已经忘了当时在想什么 有 CI bug 在 6 分钟后被发现 嫌疑范围：★ 你刚才那 40 行 排查：2 分钟 修复时你脑子里那段逻辑还热着

同样一个 bug，成本差了两个数量级。

所以衡量 CI 有没有用，不要看"bug 变少了吗"，
要看：“从出问题到定位到具体原因，要多久？”

这个时间从"一天"变成"五分钟"，就是 CI 全部的价值。

三、CI 最常见的死法不是被关掉，是被无视。

几乎没有团队会正式宣布"我们不用 CI 了"。
CI 的死亡过程是这样的：

第 1 周 CI 红了，大家紧张，立刻修 ✓ 第 1 个月 有个测试老是随机失败，重跑一下就好 第 2 个月 "重跑一下"变成条件反射 第 3 个月 CI 平均要跑 25 分钟了，没人优化 第 4 个月 大家提交前不看 CI 了，反正也慢 第 5 个月 主干红了三天，因为"那个失败是误报" 第 6 个月 ★ CI 还在跑，服务器还在烧钱 但没有任何人看它了

杀死 CI 的从来不是技术问题，是三件小事：

① 太慢 → 大家绕过它 ② 不稳定测试 → 大家不信它 ③ 红灯不修 → 大家习惯它是红的

这三件事任何一件失控，CI 都会在几个月内静悄悄地变成摆设。

所以真正需要持续投入的，不是搭流水线（那是一周的活），
而是：

· 每季度花时间把构建速度压回 10 分钟以内 · 不稳定测试当天修掉，绝不让"重跑"成为习惯 · 红灯出现时，有人真的会停下手里的活去修

CI 是一套纪律，工具只是纪律的载体 ↓ 纪律松了，再贵的工具也救不回来