如何提高一个研发团队的“代码速度”？

　　阿里妹导读：Code Velocity（代码速度），体现了一个研发团队快速响应业务需求的能力。如果做得好，代码从 commit 到上线可能平均只需要两三天时间，甚至连紧急发布都不怎么需要了。

　　今天，蚂蚁金服国际事业群技术风险部研究员南门，将和大家聊聊 Code Velocity，希望能在团队效率问题方面，为你带来一些启发。

　　 什么是代码速度（Code Velocity）？

　　Code Velocity 的定义是：一段代码变更，从 git 里的 commit time，到在生产环境里运行，中间经过了多少时间。换句话说，代码从写完开始，多快能到达生产环境。

　　举个例子，C公司的一个团队，他们今天的 code velocity 一般在是 2-4 周左右：

　　他们的一个典型的迭代周期是 4 周⁽¹⁾：第一周系分测分，第二、三周 coding、testing、修 bug，第三周末或第四周初合并回 master、部署集成测试环境、跑回归、上预发、上生产环境。在这样的迭代节奏和“分支开发、主干发布” ⁽²⁾ 的模式里，从 commit time 到进生产环境，平均是 2 周左右。

　　他们还有一些比较长周期的项目。例如，有几个项目是四月中上旬拉的分支，一直到五月下旬才合回 master，六月初发布上线。从四月上旬到五月下旬，这几个项目分支里的代码没有合回 master 过。这几个项目的 code velocity 就比较长，平均是 4 周左右。

　　 为什么要度量和提高 Code Velocity？

　　Code velocity 体现的是一个研发团队快速响应业务需求的能力。

　　以上文C公司这个团队今天的快速响应、交付的能力水平，在两周一次发布窗口的节奏里，大部分时候可能已经够了，但一旦遇到各种意外，就捉襟见肘了，例如：临时封网，需求变更，项目因故延期等。

　　快速响应、快速交付的能力要有一定的“储备”，这就好像足球运动员要有体能储备：要想赢下加时赛，就要有踢两个加时赛的体能。研发团队要能在两周一次发布窗口的节奏里游刃有余，就要有一周一发甚至一周两发的能力。况且，可以预见在不远的将来，两周一次的发布窗口也嫌太久了，业务压力会倒逼一周一发成为常态。那时候，这个团队就要有“天天发”的能力，才能游刃有余。

　　研发团队的 code velocity 和他们拿到的业务结果之间的关系，就像饭店上菜时间长短和生意火不火之间的关系一样，两者是相关的，但不是强因果关系：

• 有些饭店上菜挺快的，但生意不火。不能就因此说“上菜时间长短”不重要。

• 有些饭店，上菜很慢，但生意也还是很火。也不能因此就说“上菜时间长短”不重要。

　　一家饭店要火，还要看地段、装潢、菜单、原料、厨子、服务员、宣传等。

　　除了快速响应业务需求以外，提高 code velocity 还能帮助开发和测试同学降低项目并发、减少上下文切换、提高幸福感。在两周一次发布窗口的节奏下，很多时候研发同学把一个需求写完、测完，要等其他需求，等集成环境测试，再回来搞一波，然后到了生产环境发布再回来搞一波。事情是不连续的，开发测试其实是被打断的。Code velocity 提高了以后，开发测试有连续性，写完了测完了的代码就发走了，研发同学也不用身上同时背着一串项目了。

　　 为什么 Code Velocity 快不起来?

　　仔细想想，一段代码从 git commit 到生产环境，这个过程中时间大部分是花在等待上的：等着和其他代码一起发布上线。之所以会要把很多代码合到一起，每两周发一次，是出于 cost vs. benefit 的权衡：

• 每次常规发布，不管 payload（即发布的代码量）有多大，有些固定工作是逃不掉的：

　　首先，由于采取了“分支开发、主干发布”的模式，代码要从各个项目分支和迭代分支合并回 master，要解决冲突，确保合并时没有漏代码。

　　然后，要对 master 里的代码跑一次全量的回归：准备环境、部署代码和配置、执行回归测试用例、分析结果。这个过程做一遍，短则半天一天，长则两三天甚至更长。如果发现问题，需要修 bug，这个过程还要再重复。

　　与此同时，有些团队还要写发布计划，详细列出发布的步骤：要改哪些配置，各个系统的发布顺序是什么，回滚的步骤是什么，等等。发布计；划写好了还要评审。

　　最后，要走一遍发布流程：先上预发，上去以后 QA 要做预发验证；上生产环境，按照发布计划一步步做，蓝绿切流的过程中要让各个系统的 owner 确认 OK，再继续蓝绿切流。整个发布过程需要很多人的协同。

• 在某些项目中，把代码拆成小块分多次发布会增加开发的难度和工作量。

　　例如，X系统的 API 增加了一个新参数，要求Y系统在调用这个 API 的时候必须要传这个参数。如果两个系统上的代码变更一起发（而且是蓝绿发布），就比较简单。但如果把这个工作拆解成小块，开发工作就变复杂了：X的 API 新增的这个参数必须先做成 optional 的，等Y那边的代码改好发上线了以后，再把X的这个新参数改成 required。

　　另外，在有些实际项目中，实际情况比上面举的这个例子更复杂，并不是那么容易一眼就能看出来怎么拆解的。　　

　　 如何提高 Code Velocity？

　　要提高 code velocity，就要对上面提到的这些原因对症下药，提升四个关键能力：

1. 能频繁地把代码合回 master

2. 非常强大的跑回归的能力

3. 一键部署乃至无人值守发布的能力

4. 把大项目拆成小项目做的能力

　　提高 code velocity，要实现质的飞跃，第一个能力“能频繁的把代码合回 master”是关键抓手。把这个能力建设好了，提升 code velocity 的四个关键能力中的三个就具备了，因为“能频繁地把代码合回 master”有三个前置条件：

1. 实行了代码门禁

2. 有非常强大的跑回归的能力（即上面四个关键能力的第二个）

3. 把大项目拆成小项目做的能力（即上面四个关键能力的第四个）

　　代码门禁（Gated Checkin）

　　代码门禁能够确保每一个进入主分支⁽³⁾的 commit 都达到了一定的质量标准，例如：编译必须通过，单元测试和接口测试必须通过，新代码的覆盖率不能低于某个水平，静态代码扫描必须通过，等等。其实今天很多公司已经有 post-checkin 的 CI 在跑这些检查项了。代码门禁看似平淡无奇，无非就是把这些检查项从 post-checkin 挪到了 pre-checkin。但别小看这一挪，它的效果，不亚于把“当月业绩决定本月提成”改成“当月业绩决定下月提成”的效果。

　　代码门禁是很典型的“测试左移”的做法，和我们对质量的基本规律的认知也是一致的：问题发现得越早，修复起来代价越小。实施了代码门禁后，能确保主分支常年处于良好状态。代码门禁实施起来也很容易，很多开源和商用的 CI/CD 平台都支持，例如 GitLab+Jenkins。

　　只要做得好，代码门禁是不会降低工程师的日常效率的。“做得好”的标准是：

• 执行时间：一般能接受的是 10-20 分钟，95% 的情况下不应超过 30 分钟，否则体感就不好了。

• False negative 率：也就是说，代码门禁如果失败，有多少比例是因为代码（包括测试用例代码）本身的确有问题，有多少是因为代码门禁的 infrastructure 的问题（比如，底层机器的资源和稳定性）。一般来说，要把 false negative 率控制在 5% 以下。False negative 率如果达到 20%-30%（也就是说，五次失败里面就有一次失败是跟提交的代码变更无关的），团队里面就会开始怨声载道了。

　　 非常强大的跑回归的能力

　　有了强大的回归能力，就能在代码频繁的合并回 master 的情况下，仍然保持 master 分支处于可发布状态或者接近可发布的状态，有了强大的回归能力，我们甚至可以把一小部分的回归放到代码门禁里面去跑，那将会进一步有助于保持 master 分支处于可发布状态。

　　回归能力的强大体现在以下几方面：

• 无人值守：准备环境、部署代码和配置、执行测试、拿回结果，整个过程都必须没有任何人的参与。

• 频次：跑回归不嫌多，最理想的是每次 CI 都跑回归，那样发现问题更早、定位问题更精确。

• 覆盖率：主要是业务覆盖率⁽⁴⁾。

• 稳定性：很高的通过率，很低的噪音率，结果非常 repeatable。

• 执行时间：也许 6 小时和 4 小时看上去没有什么大差别，其实是有本质区别的。如果回归跑一遍要 6 小时，那么“改代码-跑回归-看结果”这个过程一天只能干两轮；但如果回归一遍只要 4 小时，那么这个过程一天就能干三轮。如果能再缩短到 2 小时，一天就能干六七轮。

　　这几方面的回归能力相互之间是相辅相成的，能够形成正循环，产生“飞轮效应”：

• 回归的运行，只有真正做到了无人值守，才有可能长期高频次运行。

• 高频次的运行，可以充分暴露各种稳定性问题，提高回归的稳定性。

• 缩短执行时间，一方面可以缩短“反馈弧”，加速各种稳定性问题的修复，另一方面可以提高测试环境的“周转率”，在不增加硬件成本的前提下实现更高频次的回归。

• 提高了稳定性，可以缩短用于分析回归结果的时间。如果一个有5,000 个用例的回归用例集只有 90% 的通过率，那每次跑完回归有 500 个失败的用例需要分析

  ⁽ ⁵⁾。但如果通过率有 99%，那就只有 50 个用例需要分析了。

　　强大的回归能力的背后需要的支撑能力是：

• 优质的测试环境：要在预算允许的范围内，确保测试环境的稳定和资源充沛，这样才能支撑起回归的稳定性和高频次执行。

• 配置代码化（configuration-as-code）的能力。今天常见的 web-based centralized 配置变更管理模式不足以支持高频词、高并发的回归运行模式。实现了配置代码化，才能实现快速的环境部署，以及在不同的环境之间用不同的配置跑回归。配置代码化并不是简单地把配置写在 config 文件里面，和代码一起打包发布。配置代码化是对这种 config 文件做法的否定之否定：配置可以在 git 里面修改；配置也可以在配置管理系统里面直接修改，变更会回沉到 git 里面。部署的时候，部署工具会把 git 里面的配置值以增量的方式推到配置管理系统里面。

　　 把大项目拆成小项目做的能力

　　如前所述，把代码拆成小块分多次发布，的确是会增加开发的工作量的。有不少开发同学不理解为什么要这样做。增加了这些工作量，能让我们的研发模式更加敏捷。这个代价是值得付出的，这些额外的时间是值得花的。

　　大项目拆成小项目做的一些常见套路包括：

• 分两部走：先向下兼容，再去掉兼容性。这就是前文举的那个例子：X系统的 API 增加了一个新参数，要求Y系统在调用这个 API 的时候必须要传这个参数。拆成小项目的拆解方法是：首先，X的 API 新增的这个参数做成 optional 的，把X发布上线。然后等Y那边的代码改好发上线了以后，再把X的这个新参数改成 required，再发布一次X。或者，也可以用一个 feature flag 来控制这个新参数是否 required。

• Feature flag：有了 feature flag，新功能的代码写了一半也没关系，可以把 feature flag 关掉，就算代码发上线了也不会被执行到。有时候，有些新功能所需要的代码变更是改动在老代码里面的。这样的代码变更无法用 feature flag 来屏蔽。但这也没关系，因为我们有强大的回归能力，能尽我们所能确信这些的代码变更至少不会 break 老功能、不会在发上线后造成故障。Anyway， 哪怕不是为了把大项目拆成小项目，feature flag 也是需要的。Feature flag、白名单等都是很常见的 continuous delivery 手段。

• Capability probing：很多新功能涉及整条链路上各个系统的改造。现在往往上游系统的发布依赖于下游系统的发布。解耦这种依赖关系的一种方法是让每个系统都通过一个统一的 API 接口来暴露自己当前的能力。这样，上游系统可以判断下游系统当前是否支持某个新功能所需要的能力 Foo（例如，某种支付渠道），根据结果走不同的 code path。

• 按域独立发布也是一种很成熟的拆分的方法。按域独立发布，实现域和域之间的解耦，能减少每次发布的系统的数量，降低发布风险，增加发布的灵活度。

　　大项目拆成小项目，还需要有比较强的需求拆分的能力：能够把一个全链路级别的需求文档拆分成域级别、系统级别的需求，这样每个域、每个系统可以“分而治之”。

　　 Code Velocity 和质量、线上稳定性的关系

　　从上面的分析可以看出来，提高 code velocity 并不是以牺牲质量为代价的。上面这些提高 code velocity 的手段，并没有 cut corner，并没有降低质量标准，并没有比今天少执行任何测试。即便是频繁的把代码合回 master，即便是把大项目拆成小项目做，该运行的各种验证和测试还是继续运行。而且，为了要提高 code velocity，实行了代码门禁，建设了强大的跑回归的能力，反而是对质量有提高作用的。

　　提高 code velocity 也并不会降低线上稳定性。把大项目拆成小项目做、更加频繁的发布小块代码，能够降低单次发布的风险；发布中如果出了问题，因为 payload 小，排查和回滚也更方便。另外，在投入资源提高 code velocity 的同时，我们不会降低对故障发现能力、止血能力、应急能力、监控核对等能力的投入。提高 code velocity 不会导致线上技术风险防控体系变弱。

　　 将来

　　如果一个团队的“能频繁的把代码合回 master”的能力做得足够好了，就可以完全抛弃项目分支和迭代分支，每一个 commit 都直接 checkin 进 master，而且 master 分支每天都有若干个可以发布的版本⁽⁶⁾，每个版本都可以用一个不同的 release 分支来保存。这就是所谓的“主干开发、分支发布”（Trunk-based Development）模式了。

　　到那时候，就有做到“天天发”的能力了。那时候，代码从 commit 到上线可能平均只需要两三天时间。那时候，因为有了“天天发”的能力，甚至连紧急发布都不怎么需要了。

　　 【注】

　　1. 一般会有两个为期四周的迭代并行，每个迭代有自己的目标发布窗口。发布窗口一般是每两周一次。

　　2. “分支开发、主干发布”的开发模式来自于 A successful Git branching model。但这种模式在实践中是有不少问题的（参见 A succesful Git branching model considered harmful）。更好的模式是“主干开发、分支发布”（aka. Trunk-based Development)

　　3. 主分支可以是 master，也可以是项目分支或者迭代分支。

　　4. 单元测试和接口测试看代码覆盖率，回归测试看业务覆盖率。这在行业内的一部分开发和测试之间已经形成共识了。

　　5. 当然，我们可以用技术的手段使得分析 500 个失败的用例变得更容易。但这并不应该成为我们不去提高通过率的理由。

　　6. 版本：对于“大库模式”(monolithic repo)来说就是一个 commit，对于“小库模式”来说就是每个 repo 的一个 commit 构成的一个“截面”。