从版本制发布到持续发布的演进之路-张裕

优化需求交付的时延 同时服务于SaaS和私有化客户的系统，如何持续提升交付效率 张裕阿⾥云云效产品架构师 个⼈简介 张裕 阿⾥云云效产品架构师、⼯程效能专家。 曾在某通信设备企业负责测试⾃动化和DevOps平台建设，在多个企业中担任过开发、运维负责⼈、测试架构师、教练等⻆⾊，是《阿⾥巴巴研发效能三板斧》的课程主讲 ⼈，也是BizDevOps⼯程标准的核⼼贡献者，推崇持续、快速、⾼质量的软件交付⽅式。 PART1/PART2/PART3/ SaaS产品团队开启私有化交付的挑战 按价值链重构交付链路 交付链路重构的问题与反思 PART1 SaaS产品团队开启私有化交付的挑战 没法按期按质交付客户的需求 SaaS系统 !"# !"$ !"C SaaS版本和客户私有化版本的需求存在差异甚⾄冲突 交付的是⼦系统，但SaaS版本的⼦系统边界不清晰 版本的升级难度⼤、⻛险⾼ 版本数量多，差异⼤，需要搭建和维护单独的测试环境 SaaS版本的新功能很难合⼊私有化版本 1.1案例：某企业脱胎于SaaS系统的私有化交付 1.2限定交付时间 需求频繁上下⻋ 时间倒排 开发加强⾃测 周末加下班赶⼀赶 功能先有，后续再优化 版本冲刺 …… 版本交付给客户之后，需要⼏个⽉的时间才能稳定 BOSS 后续版本的交付越来越难，甚⾄⽆法按期发版 技术债务⼤量累积 1.3限定交付范围 紧急需求排不进去 业务和技术对⽴ 定流程、定规范 版本规划会 需求冻结版本冻结 测试封版 …… 流程越来越重，需求越发越少 团队协商 质量并没有变好 1.4SaaSvs私有化交付 永远只需要关注最新版本 历史版本只要还在维护期就需要关注 只有⼀个产品形态 不同的客户可能有不同的产品形态 产品团队⾃⼰运维 客户⾃⾏运维或定期上⻔运维 随时可以发布，经常采⽤灰度或分批的⽅式 需要协商发布节点，为避免⻛险可以选择晚上停机发布 基础设施由⾃⼰选择和运维 适配客户基础设施，基础设施由客户运维 PART2 按价值链重构交付链路 1.定义研发单元和交付单元：产品和应⽤ 2.管理应⽤变更和版本发布 2.1问题分析与应对⽅案 影响 !"-.NO -.67H ABCDE -.IJKLM &':;*<= 现象 !"23/01 !"-./01 45P91 >ƒ53@ QRST/01 4567891 根因 FG53@ &'()*+, 3.减⼩集成交付的粒度 &':;*<=4567891 ⼤前提：⼀份代码、⼀套系统 应⽤：研发的最⼩单元 服务太⼩ 研发：应⽤的组合 应⽤.git 产品：售卖的最⼩单元 系统太⼤ 交付：产品的组合 产品编排.git 交付单元：产品 研发单元：应⽤ A B a b c d e C f g h 版本 UV fl[ 45 YZ [\ [\23 45[\]^ UV bcd ee bcf Jghid bcd ee bcf Jghij fl[l` WX WX-. _`-. JgC Jg$ Jg# 1.⽤版本选择业务需求范围 2.按应⽤变更承接开发任务 3.按产品进⾏集成发布 bcd ee bcf Jghik 提出需求 -.Z4 -.;n -.op -.qr [tu &'67 -.YZ 每3⽉每3⽉每3⽉ 客户 Jgfl[ Jg45 WX45 WXYm &'45 &'>ƒ &'YZ 每周每⽉每3⽉ 拉动 提出需求 -.Z4 -.;n -.op -.qr [tu …… &'67 -.YZ 客户 按需每1⽉每3⽉ 每周每2周每1⽉ Jgfl[ Jg45 WX45 WXYm &'45 &'>ƒ &'YZ 拉动 提出需求 -.Z4 -.;n -.op -.qr [tu WX67 -.YZ 客户 按需每1⽉ 按准⼊ 按准⼊ 按准⼊ 按准⼊ Jgfl[ Jg45 WX45 WXYm WXYZ PART3 交付链路重构的问题与反思 3.1问题 把更⾼层级的集成验证左移往往不能提⾼集成的效率 仅仅将交付对象由系统变为产品，⽆法做到独⽴交付 按有序和强⼀致流程进⾏交付管理往往⼒不从⼼甚⾄适得其反 3.2反思 为了提升交付能⼒，必须站在整个研发视⻆重构价值交付链路 更⼩的交付粒度，更少的交付阶段，是提升交付能⼒的基本逻辑 从管理整个交付过程，切换为定义交付阶段准⼊准出 塞外吏⼠，本⾮孝⼦顺孙，皆以罪过徙补边屯；⽽蛮夷怀⻦兽之⼼，难养易败。今君性严急，⽔清⽆⼤⻥，察政不得下和，宜荡佚简易，宽⼩过，总⼤纲⽽已。 -102年，任尚接替班超为⻄域都护，班超临⾏前的嘱咐 Thanks