持续集成 持续交付实战

ddfgd · 2018年06月28日 · 最后由 徐汪成 回复于 2018年09月06日 · 7376 次阅读
本帖已被设为精华帖!

持续交付实战

公司间竞争体现在产品、技术、效率、运营等多个维度,业务发展要求技术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自动化”,这个说来话长,先画个业务架构图放这里,下回分解。

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

共收到 41 条回复 时间 点赞

虽然不怎么懂,但我只能说:“溜溜溜溜”

架构清晰,平台功能齐全,赞一个。。。
期待后续分享

hellcat 回复

哪里不懂,我已经尽量说大实话了

Roger 回复

对拿部分比较感兴趣,我可以详细说说

楼主,下次出文章,请打开赞赏功能,我出点绵薄之力。比较关心这一套,是如何建起来的,投入了多少人,爬过多少坑,写过多少代码。哈哈哈

非常赞同,楼主关于对“需求”的分析,就是这样的“没有底线”,这样的“欲求不满”😂

楼主,在工具选择上有没有踩过什么坑

思寒_seveniruby 将本帖设为了精华贴 06月28日 22:07

用例生成器PICT吧?

通过ATC平台实现对完成评审立项的需求自动建立git分支、自动分配开发测试灰度发布机器、自动注册各种服务和监控、自动配置弹性计算和负载均衡平台等一站式保姆服务。
这块后面能详细介绍一下吗

PICT跟笛卡尔积用例设计差不多

ddfgd #12 · 2018年06月29日 作者
windanchaos 回复

赞赏先不用,可以加个微信,想我深入写写哪里,可以深入聊: 一吧七o一o一珊珊18

ddfgd #13 · 2018年06月29日 作者
ola嘿嘿 回复

工具选择有一堆的坑,这个涉及自己造轮子的投入产出比,我会详细写写的

ddfgd #14 · 2018年06月29日 作者
yangxiangfu 回复

ok,这是一系列的工具

好奇第一张ATC的图,这个ATC全称是啥?是open source的吗,google和github找了一圈没有。。。

ddfgd #16 · 2018年06月29日 作者
Kevin Gu 回复

atc (advanced test center)自己写的。。因为以前主要负责质量和效率。。所以起了这么个名字

ddfgd 回复

:)好吧,怪不得,搜的结果都是air traffic control ...
和公司著作权有关吗,考虑开源不,感觉对于leader层次的管理会有较大帮助。
我们现在的流程松散在多个技术栈里,不集中,没有统一的地方让每个工程人员都能直观的了解全局情况。

ddfgd 回复

😀 加油

内容很不错!建议楼主排个版

ddfgd 回复

从无到有,逐步迭代完善,过程中的踩坑补锅,这些能写出来的话是一个很值得学习和借鉴参考,估计都可以出书了。哈哈
另外对于硬件环境的选型配置搭建不知道有没有些心得体会可以分享?里面估计也会有很多精彩的故事。😀 😀 😀

ddfgd #21 · 2018年06月29日 作者
simple 回复

好的,这篇是抛砖引玉,后续我争取写成系列

666啊,请问这一套体系产生了哪些实质的价值?

spring-ssh 回复

嗯 我只是想提醒下作者图里写的是 PCIT

ddfgd 回复

用例生成器是PCIT还是PICT?

好顶赞😘

厉害厉害,想问一下楼主做这个大概花了多少人力呀?

分析的很详细,多谢分享,我想问下这套搭下来花了多长时间?大概几个人?

ddfgd #29 · 2018年07月03日 作者
jeky2017 回复

看公司的情况落地,做任何事都考虑投入产出比。。。
流程是双刃剑,以解决痛点为出发点。。。而不是把一整套东西都强加给别人。

所以了,1-2人可以。10几个人也可以

Roger 回复

硬件选型?你指机器采购吗,这个真不懂。我懂的都是软件或结合部分。

顶贺老板😀 ,期待系列落地文章

很溜

期待后续文章早日发表~~

很全面,不知能参考下源码吗?或者有设计文档说明吗?有些地方还是不清楚。

自己开发的?

楼主什么语言开发的,这个页面的主题,跟我一样,我只写了接口自动化的东西,楼主这东西比我多了去了,我用python+django 写的,希望可以好好交流一下

tester 回复

前端模版组件,无需区分后端语言

这个模板有点像是飞冰的。。楼主,里面的bug管理系统,是不是链接到了jira或者其他的系统中?

请教下基于作者的经验,在ci到cd这张图里面从code commit到release,也就是1-5全部走好,控制在多少时间内?其中自动化测试总共占多少时间,如果有测试fail,发现code defect的几率有多大?谢谢!

Performance的测试请教下CD中如何体现?

仅楼主可见
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册