阿里通过度量把发版过程的不确定变成确定 - 构建闲鱼版本持续交付管道及度量

2018 财年初为了应对闲鱼业务和技术快速发展。闲鱼技术团队在云效中心敏捷教练的指导下闲鱼客户端的泳道研发支撑项目 kickoff。

确定了端侧的研发模式从“小瀑布模式”到“泳道”持续集成的转变。

确定了端侧 2-1-1 的核心愿景目标。因为端侧依赖打包，适配验证等必要环节。

目标设置为 2-1-7。

即：“2"指的 2 周的交付周期，85%以上的需求可以在 2 周内交付；第一个“1”指的是 1 周的开发周期，85%以上的需求可以在 1 周内开发完成；第二个“7”指的是 7 小时的发布前置时间 - -拉集成代码后可以在 7 小时内完成发布。确定核心目标很关键，但执行和支撑也同样重要。

我们做了哪些事情？核心目标 ：“2-1-7” 实施的效果如何呢？下文主要从几个方面介绍：

一、建能力

背景：集团 AONE（云效）系统针对服务端做了比较多持续集成的支撑，但缺少支撑端侧持续集成的支撑系统，我们建立了两个平台 fishci，fishgurad。

• fishci 主要实现了端代码监控，项目打包，测试件触发的能力。

• fishguard 主要 建立了 测试包，测试机，测试任务和通知管理的能力。两个平台的设计思路是：

 - 低投入，围绕核心功能展开，做功能最小集合。

 - 充分复用已有集团已有中台平台能力。

• 研发无人化理念建设：测试件自动构建，触发运行自动化

串联系统 

由此建立了 1 次代码提交（commit，push，merge request ）到实时出端主干回归测试结果持续集成能力。

同时沉淀了整个端侧研发效能和质量的过程数据。

二、建度量

目标达成，度量很关键，度量决定了我们做的事情在目标大方向上是否偏离，距离目标还有多远。所以对 2-1-7 核心目标做度量之外，我们还需要分解过程目标。

fishci 和 fishguard 两个平台支撑了端侧的代码变更，编译打包，触发数据，测试件运行数据，沉淀在平台的这些数据就具备了版本运营的能力。

技术 PM,PTM，TL 可以通过数据关注版本运行状态，跟踪和做持续的改进。

三、改过程

泳道集成研发过程整体图：

• 研发分支管理：需求关联分支，develop 分支，develop 和 release 管理，合入代码

  
  

  评审卡口。

• 端开发：端架构升级。

• 测试技术：端侧 UI 测试件自动构建和回归，端性能测试自动化，端侧 monkey 自动化触发。

• 流程卡口：需求 aone（云效）管理，新建代码 review 卡口，新建集成质量卡口，发版质量标准，新建性能测试集成卡口。

四、版本研发度量数据：（度量数据更新到 3 月份底）

1、发版效能和需求吞吐量：

发版准时率度量：20/21= 96%

需求吞吐量（按月）：

结论：需求吞度量逐步提升。3 月底需求吞吐量达到历史最高。

---使用合入 develop 分支的分支数度量（每一个分支对应一个 aone（云效）需求编号）

研发耗时：

需求“端”到“端”接手开发到开发测试（自测）时间即效能数据，（2-1-7）中的 1 度量数据：使用泳道第一次 push 代码的时间---合入 develop 的时间做度量。

结论：开发到合入主干时间，之前无度量数据。

通过数据暴露的问题 1 月份泳道研发分支大需求过多，导致平均研发周期在 2 周左右，（玩家，社区）。

我们的工程体系对需求的拆分支持的还需要提升，后面把闲鱼社区做独立 bundle 的拆分。

三月份研发周期下降到 1 周左右。接近目标。

2、持续集成效率核心数据：

集成效率核心数据

使用合入 develop 分支的变更频次和变更规模度量的 task 的次数和代码规模（文件数）。

结论：可以看到，持续集成的按月次数提升，提交分布更均匀，持续集成的节奏在朝着正确的方向运转。

发布效率：从拉集成分支到发布

泳道模式前：1 周目前版本：平均 1.5 天

3、集成质量核心数据：

集成后变更规模：

使用 release 分支变更频次和变更规模度量，越少越好。

结论：release 分支提交次数在明显上升，需求吞吐量增加的同时，集成后代码质量下降。这是我们效率增加后质量的负向指标也升高，风险在增大。

总缺陷在泳道阶段，集成阶段的缺陷走势。

结论：缺陷总数趋势稳定，提测阶段缺陷数在增加，集成后的缺陷占比在下降。

泳道提测质量和遗留到集成阶段缺陷趋势。

（major bug+低级 bug 数）

结论：泳道提测质量恶化，质量压力持续增加，1 月份提测质量达到最差。项目风险也最高。

三月份有所下降，质量压力好转。

提测缺陷密度和遗漏到集成阶段缺陷密度趋势。

（ 加权*10000 度量开发缺陷密度）

结论：随着开发提测质量随着需求吞吐量提高，提测阶段缺陷密度恶化，遗留到 release 阶段缺陷密度有下降，依赖测试的泳道测试中的效率提升（发现更多的缺陷）。

三月份，需求吞吐量增高，变更量增大的情况下缺陷密度好转，整个质量压力好转。

五、小结

1. 使用这些度量数据看可以得到结论，我们的研发过程从小瀑布集中式到泳道分布式持续集成，需求吞吐量增大，质量数据更透明，效能有明显的提升。

2. 数据暴露问题看我们距离目标还有一定的差距，但从度量角度看这些问题数据是很有意义的。这些数据在度量之前是不可知的，也无从分析改进的切入点。现在可以通过改进 action 和数据验证 形成闭环 来确定改进效果和方向。向正确方向行进很重要！同时通过平台设置质量卡口，使得我们的过程质量更透明和可控。（有趣是，设置了更多，更严格的质量卡口之后，整个效能数据并没有变差。）

3. 总之通过这些度量数据，我们可以度需求吞吐量（多），需求响应速度（快），集成频次（好），缺陷收敛和缺陷密度（好），投入资源情况（省）。

   
   

   如何评估研发效能，我的思考是通过数据可以拟合一张图（如下图。）

X 曲线才是我们的期望曲线。其他曲线都值得去监控和改进。

本文作者：韩越峰

【关于云效】

云效，云原生时代一站式BizDevOps平台，支持公共云、专有云和混合云多种部署形态，通过云原生新技术和研发新模式，助力创新创业和数字化转型企业快速实现研发敏捷和组织敏捷，打造“双敏”组织，实现 10 倍效能提升。

立即体验