通过度量把发版过程的不确定变成确定-构建闲鱼版本持续交付管道及度量 | 实践案例三

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

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 主要 建立了 测试包,测试机,测试任务和通知管理的能力。两个平台的设计思路是:

 - 低投入,围绕核心功能展开,做功能最小集合。
 - 充分复用已有集团已有中台平台能力。

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

串联系统

image.png

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

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

二、建度量

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

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

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

三、改过程

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

image.png

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

评审卡口。

  • 端开发:端架构升级。
  • 测试技术:端侧 UI 测试件自动构建和回归,端性能测试自动化,端侧 monkey 自动化触发。
  • 流程卡口:需求 aone(云效)管理,新建代码 review 卡口,新建集成质量卡口,发版质量标准,新建性能测试集成卡口。

四、版本研发度量数据:(度量数据更新到 3 月份底)

1. 发版效能和需求吞吐量:

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

需求吞吐量(按月):

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

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

image.png

研发耗时:

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

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

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

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

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

image.png

2. 持续集成效率核心数据:

集成效率核心数据

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

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

image.png

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

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

3. 集成质量核心数据:

集成后变更规模:

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

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

image.png

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

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

image.png

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

(major bug+低级 bug 数)

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

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

image.png

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

( 加权*10000 度量开发缺陷密度)

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

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

image.png

五、小结

  1. 使用这些度量数据看可以得到结论,我们的研发过程从小瀑布集中式到泳道分布式持续集成,需求吞吐量增大,质量数据更透明,效能有明显的提升。
  2. 数据暴露问题看我们距离目标还有一定的差距,但从度量角度看这些问题数据是很有意义的。这些数据在度量之前是不可知的,也无从分析改进的切入点。现在可以通过改进action 和数据验证 形成闭环 来确定改进效果和方向。向正确方向行进很重要!同时通过平台设置质量卡口,使得我们的过程质量更透明和可控。(有趣是,设置了更多,更严格的质量卡口之后,整个效能数据并没有变差。)
  3. 总之通过这些度量数据,我们可以度需求吞吐量(多),需求响应速度(快),集成频次(好),缺陷收敛和缺陷密度(好),投入资源情况(省)。

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

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

image.png

                                                                本文作者:韩越峰

lQLPDhsB-6_MTiPNBDjNB4CwJ0odfQ_xJCgB0-wc0wAZAA_1920_1080.png

相关文章
|
新零售 测试技术 持续交付
阿里如何定义团队的研发效能?
作者:何勉,阿里巴巴研发效能部资深技术专家 相关阅读:都996了,研发效能还是提不起来,关键在这里 因为身处研发效能部,我接触了公司很多产品技术团队。他们几乎都把研发效能提升列为了本财年的重要目标,大部分还为此成立专项。
19022 3
阿里如何定义团队的研发效能?
|
缓存 Devops 物联网
阿里巴巴DevOps实践指南(六)| 产品导向的交付
业务驱动和产品导向是适应数字化时代要求的协作和交付方式,是我们对 DevOps 实施的核心价值主张。同时,它们的有效实施离不开工程实践和能力的支撑,下一章我们将讨论 DevOps 的另一核心要素——持续交付的工程能力。
阿里巴巴DevOps实践指南(六)| 产品导向的交付
|
SQL 运维 监控
阿里巴巴DevOps实践指南(二十一)| 全景监控
随着云原生技术的发展与演进,微服务和容器化技术成为大型分布式 IT 架构的必然选择。新技术在让 IT 系统变得更敏捷、健壮、高性能的同时,也带来了更高的技术架构复杂度,给应用监控带来了前所未有的挑战。
阿里巴巴DevOps实践指南(二十一)| 全景监控
|
运维 Devops Java
阿里巴巴DevOps实践指南(十三)| 测试提效
分布式测试为测试速度插上了翅膀,精准测试有效的识别出了测试的范围,增量覆盖率又为测试的不断完备提供了有利的指引,线上覆盖率帮助我们有效的进行应用瘦身。充分利用好这些技术手段进行测试提效,可以让持续交付的过程更加的顺畅
阿里巴巴DevOps实践指南(十三)| 测试提效
|
安全 算法 Java
5种阿里常用代码检测推荐 | 阿里巴巴DevOps实践指南(十二)
随着业务演进和团队扩张,软件规模和调用链路越来越复杂。如若没有良好的代码检测机制,只依靠功能性验证,团队技术债会越累越高,开发团队往往要花费大量的时间和精力发现并修改代码缺陷,最终拖垮迭代进度、协作效率,甚至引发严重的安全问题。
5种阿里常用代码检测推荐 |  阿里巴巴DevOps实践指南(十二)
|
9月前
|
JSON 监控 API
京东商品列表 API 接口系列(京东 API)
京东商品列表API接口为开发者提供获取店铺内商品详细信息的功能,包括名称、价格、库存、图片、ID、销量等。通过HTTP GET请求并包含必要参数(如店铺ID、API密钥),可获取JSON格式的商品列表数据,适用于展示、库存管理、价格监控等场景。示例代码展示了使用Python调用该接口的方法,返回的数据包含状态码、商品总数、分页信息及具体商品详情。
|
人工智能 运维 Kubernetes
深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
研发效能提升不知从何下手、一头雾水?阿里资深技术专家一文为你揭秘研发效能提升的系统方法
4845 1
深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
|
存储 弹性计算 中间件
|
Devops 测试技术 持续交付
阿里巴巴DevOps实践指南(五)| 业务驱动的协作
明确需求层次以及每个层次承载的价值之后,接下来要做的是定义每个层次的协作过程,最终服务于“顺畅高质量地交付业务需求”这一目标。如何组织各个层次的协作,来达成这一最终目标?
阿里巴巴DevOps实践指南(五)| 业务驱动的协作
|
运维 Cloud Native 数据可视化
2018-2021,60+篇阿里研发效能提升干货,都在这里了
今天,正值2021的最后1天,我们精心盘点了2018-2021连续3年来,云效团队在研发效能提升方面输出的所有干货,希望对大家有所帮助。
5298 3
2018-2021,60+篇阿里研发效能提升干货,都在这里了