共计 2412 个字符，预计需要花费 7 分钟才能阅读完成。
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 阶段缺点密度有降落，依赖测试的泳道测试中的效率晋升（发现更多的缺点）。
三月份，需要吞吐量增高，变更量增大的状况下缺点密度恶化，整个品质压力恶化。
五、小结
- 应用这些度量数据看能够失去论断，咱们的研发过程从小瀑布集中式到泳道分布式继续集成，需要吞吐量增大，品质数据更通明，效力有显著的晋升。
- 数据裸露问题看咱们间隔指标还有肯定的差距，但从度量角度看这些问题数据是很有意义的。这些数据在度量之前是不可知的，也无从剖析改良的切入点。当初能够通过改良 action 和数据验证 造成闭环 来确定改良成果和方向。向正确方向前进很重要！同时通过平台设置品质卡口，使得咱们的过程品质更通明和可控。（乏味是，设置了更多，更严格的品质卡口之后，整个效力数据并没有变差。）
- 总之通过这些度量数据，咱们能够度需要吞吐量（多），需要响应速度（快），集成频次（好），缺点收敛和缺点密度（好），投入资源状况（省）。
如何评估研发效力，我的思考是通过数据能够拟合一张图（如下图。）
X 曲线才是咱们的冀望曲线。其余曲线都值得去监控和改良。
本文作者：韩越峰
【对于云效】
云效，云原生时代一站式 BizDevOps 平台，反对公共云、专有云和混合云多种部署状态，通过云原生新技术和研发新模式，助力翻新守业和数字化转型企业疾速实现研发麻利和组织麻利，打造“双敏”组织，实现 10 倍效力晋升。
立刻体验