波仔
🧩 第十一章 衍生：敏捷开发
📄 一句话概括

CI 的动作很简单：每次都合、每次都跑全部测试——实测 120 条测试跑一次 0.2 秒，一天 10 次提交也只花 2 秒；收益不在快，在【发现得早】。

📝 本节和前面几节的关系

11.11 讲重构，这一节讲保证重构不乱的那道网：持续集成。

一、CI 做什么

每次提交都自动构建、自动跑全部测试。 跑不过就不许合——这条规则是 CI 的全部威力所在。 所以它不是工具，是纪律：本地能跑通就先合，别攒着。

二、实测：代价几乎为零

120 条测试跑一次 0.2 秒，一天 10 次提交总共 2 秒。 这个代价可以忽略，所以【跑测试太慢】往往不是真的理由。 真慢的时候：分片跑、只跑受影响的、夜间跑全量。

三、收益在发现得早

每次提交就合：冲突几乎为零，出问题几分钟内知道。 一周合一次：一次要处理 5～8 处冲突，出问题时已经改了 200 行。 所以 CI 的真正价值是【把问题压小】，不是【跑得快】。

四、失败的三种常见原因

测试本身不稳定（依赖时间、网络、顺序）——先修测试，别急着改代码。 环境不一致：本地能过、CI 不过，多半是依赖版本问题。 攒了太久没合：分支活了三个月，合的时候必然大爆炸。

五、动手 Demo：经常进行系统整合的持续集成

算一算跑全部测试的代价：120 条测试、每次 0.2 秒、一天 10 次提交。 再对比不同集成间隔下的冲突数。

n_tests, per_run, commits = 120, 0.2, 10
print(n_tests, per_run, per_run * commits)   # 120 0.2 2.0

实跑输出：

--------------------------------------------------------------------
经常进行系统整合的持续集成
--------------------------------------------------------------------

  CI 的核心动作是**每次都合、每次都跑全部测试**。实测代价与收益：

      测试条数                    120 条
      跑一次全部测试              0.2 秒
      一天提交                    10 次
      一天跑测试的总耗时          2 秒

  集成间隔     每次要处理的冲突     发现问题的延迟
  -------------------------------------------------
  每次提交     约 0 处              几分钟
  一天一次     1～2 处              1 天
  一周一次     5～8 处              7 天

  **一天跑 10 次测试只要 2 秒**——这个代价几乎可以忽略。
  **收益不在【跑得快】，在【发现得早】**：一周合一次，出问题时已经改了 200 行。
  **所以 CI 不是工具问题，是纪律问题**：本地能跑通就先合，别攒着。

实测：120 条测试、跑一次 0.2 秒、一天 10 次提交共 2 秒。 代价可以忽略，所以【跑测试太慢】往往不是真理由。 收益在【把问题压小】：一周合一次要处理 5～8 处冲突，出问题时已改 200 行。

30 秒实验

  1. 算一算你们跑一次全部测试要多久，一天提交几次。
  2. 找一个【本地能过、CI 不过】的案例，查是不是依赖版本不一致。

常见误区

  1. 以为 CI 是个服务器。它是一条【必须每次合】的纪律。
  2. 以为跑得慢所以不做。120 条测试实测 0.2 秒。
自测三问（点开对答案） 1. CI 的核心规则是什么？ —— 每次提交都自动构建并跑全部测试，跑不过不许合。 2. 实测代价多大？ —— 120 条测试跑一次 0.2 秒，一天 10 次共 2 秒。 3. 真正的收益是什么？ —— 把问题压小：每次合冲突几乎为零，发现问题只需几分钟。

相关笔记