持续交付实战

Posted 2020-12-25 tiechui2015

 

公司间竞争体现在产品、技术、效率、运营等多个维度，业务发展要求技术leader从团队、技术、流程、标准多管齐下保证自己负责的维度不成为公司瓶颈。
万事万物同理，公司或团队的发展也可以理解成三个阶段：温饱、脱贫、致富。各个阶段都有相应的建设套路，并不是一步到位就合适，温饱阶段随便几个码农就把事干了，为难的问题是脱贫到致富的升级，需要一系列技术手段以保证研发效率的提升，同时各路大神也有多种忽悠的套路。需要leader为团队量身定做一套合适的升级方案并执行到位。
研发效率的核心就是交付效率（其次是质量和人效），交付过程中一个可以量化的指标就是发版频率（或叫需求吞吐效率）。
下面分别说下影响发版效率的几个核心问题，以及我们的解决方案。
1、需求池和需求生命周期的管理
2、统一组件化能力库和代码基础类库
3、统一自动化测试框架和持续交付流水线
4、。。。。。。

问题：需求是整个研发的源头，大家都知道要控制，但实际操作中需求方一向很强势（比如直接来自老板、事故等，你懂的！）而且技术是成本部门，本身就是为业务需求服务的，同时，打造一支高需求吞吐量的团队也是技术leader的价值所在，所以不要抱怨，动起来，解决问题吧。
1、务必形成迭代和交付节奏，让研发、产品和需求方形成心理预期。同时以需求池的方式对所有需求进行统一的管理（含分级）。
2、保证需求评审和周知到位，磨刀不误砍柴工。具体可以多级评审体系：成立产品委员会和技术委员会做high level评审；开发和测试架构师做实施方案评审；开发测试业务owner做具体细节评审。
3、严肃需求变更：正常的敏捷流程大家都会，而且流程是双刃剑，流程越多越说明管理的垃圾，所以把有限的精力focus在最高风险的地方。严格执行审批和周知（这涉及一个心理学因素，一件事情不可避免，就人为增加流程成本以降低发生概率）
4、需求生命周期流水线dashboard，让研发团队的交付透明化和数据化。如下图，可以清晰知道每个需求开发测试、灰度的状态，以及线上运营数据反馈，甚至实时数据大盘。

 

 

问题：随着团队的扩张，让开发更专注于写业务代码。
1、建立通用分层组件库，并以code sample或IDE插件的方式提供，参考下图（盗图），

 

 

2、完善基础服务（如git、maven库、安全协议、自定义tcp等等）

 

 

3、通过ATC平台实现对完成评审立项的需求自动建立git分支、自动分配开发测试灰度发布机器、自动注册各种服务和监控、自动配置弹性计算和负载均衡平台等一站式保姆服务。
4、“代码只有在被正确的环境中才能正确的运行”，这句话有点拗口，但意思就是“配置就是代码，要和代码一样对待”所以统一配置中心、k8s docker的引入必不可少。devops的理念也是“everything is code”。

问题：交付要求“又快又稳”，所以必须建立一套高效的质量保证体系，做好发布前和发布中测试。同时互联网时代要“小步快跑”，所以多级灰度发布、数据反馈、问题定位系统也必不可少。
1、横向全面测试必不可少，该干的不能偷懒，如图，查漏补缺。当然，根据公司业务技术特点识别出质量高风险点是衡量测试leader的重要标准，因为资源总是有限的。

 

 

 

 

 

2、纵向的CI流水线能够极大提高交付效率，建立BVT和release gate的机制以降低人为参与和提高自动化率（从实践看，自动化率低才是流水线失败的最大原因）

 

 

3、测试leader都有过半夜2点被老板拎起来的经历，因为测试是兜底的，不管啥问题，大家第一反应都是测试的锅，但实际上具体原因到debug才能知道，所以ATC平台提供用户排查体系和智能告警系统（因为内部图还要脱敏处理，比较麻烦，所以多处盗图，说明个大概的理念，感谢原作者）
同时建议成立由开发测试运维运营等统一组成的“稳定性小组”并设立值班长制度，“团结一切可以团结的力量，结成快速响应联盟”
其次，内测群、摇一摇上bug之类的内灰机制也要搞起来。比较狗血的收集老板们用的手机型号以防止兼容性问题也是要考虑的（老板报的bug，你不复现，那不忧伤了！）

 

 

 

 

4、整个研发是成本部门，测试更是重灾区，人效更是leader永远的痛，所以必须要把整个测试数据化，数据化才是一切度量和优化的前提，ATC平台从如下维度进行数据化。同时通过data insgiht和engage的分析找出流程痛点。
Bug是report的一部分，report是测试的最根本产出（测试的意义在于确保产品达到发布标准而不是发现所有bug）。Plan分解成task（matrix是艺术、是资源协调能力和思维缜密性的最佳体现，也是高级经理的唯一考核标准）。Task：可追述的执行历史记录、个人performance的体现、kpi的度量、团队能力的积累和传承。Test case是一切的基础（树形、一句话：你说不明白是你的分析表达能力、业务理解深度不到位，他看不懂是他有这些问题）。

 

 

5、统一自动化测试平台：自动化程度决定交付流水线的效率，所以要开发一套高效的框架。这个东西简单的说照着网上的demo，5分钟就能把appium、selenium、接口测试跑通，但大规模应用就是一个大坑，所以ATC平台提供最具ROI的方案“以接口为龙头的灰盒测试+核心场景UI自动化”，这个说来话长，先画个业务架构图放这里，下回分解。

 

 

我们开发的是一站式应用全生命周期解决方案：提供从“需求->开发->测试->发布->运维->运营”端到端的协同服务和研发工具支撑，以上简单的说了下需求、开发、测试阶段，后面下回分解。欢迎大家交流，这会是一个系列文章（但愿我能坚持），也算是对以前工作的总结。