devops [持续交付实践] 从交付流水线到研发协作平台

cay · 2018年04月16日 · 最后由 xuwangcheng14 回复于 2018年09月19日 · 7674 次阅读
本帖已被设为精华帖!

前言

2017年11月前,我们基本上已经完成了Jenkins pipeline流水线上各个环节的设计和开发,这里面囊括了编译、部署、代码检查、单元自动化测试、接口自动化测试、UI自动化测试、专项自动化测试(APP专项/性能/安全等)、发布等一系列环节,完成了各个内建测试平台与jenkins pipeline的结合,当然在团队内部的应用上,还需要持续驱动。
这个时候Jenkins自身的局限性就暴露出来了,Jenkins只是很好的解决了每个应用交付流水线的问题,但随着企业业务量的增加,研发团队急剧扩张,研发中的各个环节,比如应用的管理,代码库的管理,开发测试环境的管理,发布计划的管理,发布后的监控,研发质效的度量,舆情故障的管理等等都存在无数的痛点, 任何一个环节没跟上都会严重影响研发的质量和效能。
下面是技术工程师每天的工作日常,立项,建代码库,申请资源,拉分支写代码,联调测试,发布到线上,设置监控点,质效分析和总结等等,这些活动存在于不同的平台,每天在不停的重复,需要不停的和各个团队沟通,不停的做研发平台和技术栈的切换,所以我们又回到持续交付的一个原则,如果有一件事让你感觉到痛苦,那么就尽早并尽可能频繁的去做。梳理出规范化的玩法,采用自动化的高效手段,用技术去解决这些让我们感觉头疼的问题。

这个时候就需要我们进一步把思考层次从测试团队提升到整个研发团队、整个产品团队的高度,不仅仅只是想着测试工程师怎么测试,更要想着整个研发团队应该怎么高效协同,把研发中所有的环节尽可能的标准化、自动化、透明化,靠技术而不是一大堆管理规范来解决问题,从而形成一个完整的研发闭环。跳出测试执行的小圈子去思考质量,向左在开发阶段保证编码质量,向右在生产环境保障发布质量,这也正是我所理解测试团队要在devops/持续交付模式下保持竞争力的关键所在。

QA(EP)团队的三个阶段

只是从个人经历的思考,可能不是很成熟。各个阶段的建设没有绝对的先后顺序,但后面阶段的效果会强依赖于前面阶段的能力。
google从QA团队逐步发展成了EP团队,中间的过程也是从业务测试团队,逐渐发展成质量效能平台研发、提供测试赋能的团队,这个过程会很漫长(对很多公司来说可能永远看不到),但相信是未来的趋势。
第一阶段:测试自动化,代码层,接口层,UI层、APP专项/安全/性能等各专项环节的自动化测试,搭建自动化测试平台。
第二阶段:交付流水线化,把包括自动化测试在内的各个交付环节通过pipeline的方式进行串联斜接,搭建持续交付平台。
第三阶段:研发协作智能化,除了pipeline流水线,延伸到代码管理,应用管理,资源管理,发布管理,监控管理,项目管理,研发工具云等各个研发环节,向任何研发环节挖潜,提供一站式智能研发协作平台。

技术范的公司如何开发、测试和发布

应用为中心的研发协作

建立公司级别的标准应用库,以应用为中心,这点非常重要,是整个研发协同活动的基石,应用信息对技术人员天然是亲切的,它可以直接对应一个服务,一个代码库,一个环境,一条流水线,一个监控job,一个质效数据。
我们需要依靠应用这个维度,串联整个研发协作过程,代码、资源、流水线、监控、运维、故障、质效等等都是围绕着应用维度来开展,开发、测试、运维、安全等等技术团队也就可以在各自平台上去定义它的应用,并实现无缝的衔接。
应用有了标准库,也就有了生命,有了生命周期的管理。应用不再只是一个干瘪的代号或标识,而是一个活动集合一个工作系列。无论是新建和停用,都会影响到一系列的工作环节,当然这个过程我们需要各种自动化串联。

以应用新增和停用为例
应用新增:应用基础信息提交->业务线技术主管审核->代码推荐和初始化->资源申请
应用停用:停用应用->业务线技术主管审核->运维审核->代码库自动冻结->流水线job回收->资源自动回收->监控自动关闭等等

容器化的资源管理

开发,测试,预发,发布,稍微上规模的互联网技术团队,上线前都会经历这几个阶段,每个阶段分别对应一套环境。所以我们至少会面对开发环境、测试环境、预发布环境、正式环境,在没有使用容器之前各套环境配置、软件包、资源类型等等难以保持一致。
产品线若干条,数百个应用,每个应用并发N个分支,有Java、NodeJS、PHP、C++、Android、IOS、中间件等等。
微服务和分支开发的背景下,应用和分支数量泛滥,各服务相互依赖耦合,资源管理复杂度和需求量剧增,难度不亚甚至更超过线上环境的管理。没有趁手的利器,环境稳定性差,会导致开发和测试效率都十分低下,各个应用之间的开发工作互相block,从而拖垮整个团队的项目研发。
幸好我们有了容器这个救命稻草,软件包管理、目录管理、基线变更、运维脚本等等通过一个dockfile就可以规范解决,再通过分布式配置中心(业内知名的如springcloud的config、百度的disconfig、携程的apollo、淘宝的diamond等)实现对不同环境的配置管理,基本我们就实现了环境的标准化以及运维服务的下沉,DevOps的理念才得以真正的落地。
一键化申请容器应用(还包括mysql、redis、mongdb等的标准组件)过程

研发环境特别痛苦的一个点是,每个应用都会存在大量并行分支的开发。如果全部环境混在一起,各个分支之间互相依赖互相干扰的情况会让人崩溃,而如果搞出几套独立的研发环境(比如常规分支、特性分支、紧急分支等),多套环境的维护量也同样会让人崩溃。
这里比较好的一个实践,就是区分出稳定环境(stable)和分支环境,并且将分支环境隔离。这里的分支环境可能是一个开发机,也可能是一个测试服务器,针对某个需求相互依赖的应用分支可隔离在一个环境内,而非需求强依赖的应用则可以直接连接稳定环境。
因为我们的分布式服务用的是dubbo,容器管理用的是K8S,要实现这点中间其实还涉及到不少对dubbo和K8S自身的改造。

流水线是DevOps的核心

要实现持续交付,核心在于Pipeline,要实现Pipeline,重点在于自动化测试。
如何通过自动化流水线,让需求小批量流转,实现软件短周期的频繁交付,在持续交付的文章里已经写了很多,这里不再赘述。通过研发协作平台,我们不再完全依赖于Jenkins千篇一律的界面和布局,把Jenkins作为基础设施,而不是操作管理界面,这是研发协作平台集成流水线技术的重点。
另外比较重要的一点是,有了pipeline我们还是需要有发布计划的管理。即使是在持续交付模式下,发布操作仍然是一个严肃的事情,需要非常审慎的对待,比如除了pipeline的运行结果,还要包括codereview的结果,发布窗口,人工检查的结果等等,这些都需要在研发协作平台上自动化进行结果聚合和控制。

一站式监控管理

围绕应用,我们有多维度立体式的监控体系,包括而不限于
拨测监控:系统有没有问题?
全链路监控:系统哪里有问题?
舆情监控:用户反馈了什么问题?
资源监控:主机网络有没有问题?
这里要做的是聚合,脚本化的监控要页面化,页面化的监控要归一化,通过应用的筛选,就可以看到整个监控大盘的全貌,并且通过统一的应用报警设置,建立共同的响应机制。
以拨测监控为例:

度量管理:DevOps仪表盘

管理大师彼得德鲁克:如果你不能度量它,你就无法改进它。
做事情应该以终为始,发布上线并不是项目的结束,而是另外一个迭代的开始,建立快速和持续的从右到做的反馈尤为重要,通过建设质量和效能的数据看板,让整个交付过程更加透明,暴露出瓶颈点并持续改进,这是度量管理的核心意义。
列举一些常见的度量点,这些都希望在应用的维度下系统展示,而不是在一个个内部平台上去跳转,去人工采集。
项目进度和风险大盘
需求完成率
项目及时率
代码静态分析结果
流水线执行频率、时长和成功率
发布执行频率、时长和成功率
监控报警频率和趋势
线上故障情况统计等

内部全云化的工具平台

技术团队越来越大,开发、测试、运维、安全等各种工具平台越来越多,各个BU在各个是技术方向上也都有创新的冲动,这必然也会导致不小的重复建设和资源浪费。
所以我们开始尝试内部云化的工具平台,包括内部的开发工具链平台,测试工具链平台,安全工具链平台,运维工具链平台等,将各种标准化技术平台的能力输送给各个业务线团队,提升团队整体质量和效能。

后记

春节前二宝出生,新添一枚千金,增加了无数喜悦也带来无数忙碌,时不时有坛友问起后面的文章,却总发现难以静心总结。
不仅仅是生活和工作的忙碌,也是在从pipeline到研发协作平台这个过程中,发现了太多的坑需要去填补。洋洋洒洒一篇文章下来,中间的无数细节其实都需要无数技术栈上的攻关,直至到现在,仍然感觉有很多地方需要完善改进,有许多方向可以追加。
到了这个阶段所做的其实已经远不是传统测试范围内要做的事情,我们需要考虑平台总体架构,需要考虑编码设计,需要自己去做交互设计,自己去做美工,我们没有全职的前端(虽然我也有很多办法可以要到前端资源,但更倾向去全栈开发),需要和公司内部大大小小的平台做联调和对接,需要在各个技术团队落地应用。但这一切都很有价值,团队内部应用的效果让整个研发小组(全职参与的其实没有几人)信心满满,人人充满动力团队迅速成长,所以....这会是一个招聘广告么呵呵,欢迎加入微医。

主帖直达:https://testerhome.com/topics/9977

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 36 条回复 时间 点赞
cay [持续交付实践] 开篇:持续集成&持续交付综述 中提及了此贴 04月16日 15:33

大神,wcp平台是你们自研的么?

cay #3 · 2018年04月16日 作者

嗯 内部开发,底层基于各开源工具链。提供给想做持续交付平台的朋友一些思路和方向吧。

cay 回复

能告知大概有哪些工具么?Jenkins, k8s,docker,有了这个平台就不需要直接跟Jenkins操作了?我们公司也有这个需求。目前还没什么头绪。目前我们停留在第二层。

蒋老师太棒了,上午还在交流中说到希望看到您更多分享,下午就有如此高质量的文章出现在社区👏
我们都还在交付流水线上努力那,感谢老师提供思路和方向

好文,跟我之前的想法也差不多相同。但我现在的我不太认同你说的DevOps的核心在于自动化测试,我认为的DevOps的核心在于效率的提升,无论是测试还是研发,如果手动的测试比自动化测试效率来得高那么为什么不用手动呢?

0x88 回复

欢迎交流,我从不否认手动环节的价值,很多时候都难以替代。原文是“要实现持续交付,核心在于Pipeline,要实现Pipeline,重点在于自动化测试”。pipeline是包括编译,代码检查,部署,测试,发布等等一系列环节的自动化实现,也包括你说的研发效能提升,这里最困难的是自动化测试,也是pipeline效果好坏的关键,所以我说是重点。

单从web开发来说常规的springboot+mybatis+freemarker足矣,主要涉及到与Jenkins体系,Sonar体系,K8S体系,gitlab,用户管理中心,分布式配置中心,统一发布平台,各监控平台等等的对接与集成。

chenhengjie123 将本帖设为了精华贴 04月17日 08:35

不错,今年来大会分享下经验吧。

解决大团队的能效问题,说出来只有大团队的人能理解,很多话看起来感同身受,现在的互联网里面,面试一提到给你解决团队协作的效率问题、给你提高产能……对方就不耐烦听,很少有楼主公司这么有追求的了,赞!

高产,mark

dubbo的请求通过分组策略打到stable环境上么

仅楼主可见
cay #15 · 2018年04月19日 作者
fudax 回复

经历过才知道的痛:)

cay #16 · 2018年04月19日 作者
taki 回复

根据容器环境类型做服务自动隔离。

cay #17 · 2018年04月19日 作者
tq0fqeu 回复

谢谢,暂时没有类似意向。阿里的云效和Aone很棒,向你们学习。

仅楼主可见

非常有帮助,蒋老师,我想问一下 , 你说的流程依然有各种审核,这些审核是全自动或者人工的? 如果是人工的,势必又会有新的流程瓶颈,关于审核效率的问题你们是怎么解决的?

cay #20 · 2018年04月23日 作者
leons12201 回复

容器的申请有配额,配额范围内不需审核;应用的上线和下线这种关键节点让直接技术主管审核下还是比较有必要的,但外围的操作都可以自动化,比如一旦主管同意下线,所有资源监控点之类都会自动回收掉。

投微医的什么岗位啊😀

cay #22 · 2018年04月25日 作者
shouquan822 回复

简历直达:jianggy@guahao.com。接口测试,性能测试,测试开发,java开发均有岗位。

仅楼主可见
cay #24 · 2018年04月25日 作者
Nuanyang2333 回复

可以直接发邮箱,有时候消息太多没时间看

cay 回复

查了下,工作地点在萧山么?

你好,能问下,这个平台大概用了多久么?

仅楼主可见
cay #28 · 2018年06月02日 作者
shadow000902 回复

谢谢反馈 用的第三方银行接口 不太稳定。

牛逼哈,做了这么多,我在想 你们几年才完成了这套系统的搭建和开发,这些都是测试完成的吗

cay #30 · 2018年06月05日 作者
dyw 回复

三四个月吧 基于原有的一些基础设施。

cay #31 · 2018年06月05日 作者
shadow000902 回复

换张卡试试看吧 银行端返回的错误 截图中注意个人隐私。

一篇篇连续读下来,感觉甚赞!问个问题:咱们的mysql也容器化了?如果是,咱们不同环境的测试数据是管理的?谢谢!

@cay ,你们测试人员能力要求怎样,都要开发平台代码吗, 还有基于原有基础设施,是围绕哪个核心来整合原有基础设施了.

cay #34 · 2018年06月11日 作者
dyw 回复

容器管理,pipeline流水线管理,统一配置中心,统一用户授权,gitlab代码管理平台,链路监控,代码检查平台,自动化测试平台,全链路压测平台.....各种研发环节的基础设施都做了整合,似乎很难说哪个是核心了,业务测试和测试开发编码能力要求上会有些区别,不过基础代码能力都是需要的。

先做了流水线再做的cmdb,然后再做的运维平台?

学习了

感觉远远超出了测试的范畴。
有些东西可能连开发运维都不是那么懂。

技术含量过高!!!

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