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

前言

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

 

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

QA（EP）团队的三个阶段

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

 

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

应用为中心的研发协做

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

 

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

容器化的资源管理

开发，测试，预发，发布，稍微上规模的互联网技术团队，上线前都会经历这几个阶段，每一个阶段分别对应一套环境。因此咱们至少会面对开发环境、测试环境、预发布环境、正式环境，在没有使用容器以前各套环境配置、软件包、资源类型等等难以保持一致。
产品线若干条，数百个应用，每一个应用并发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到研发协做平台这个过程当中，发现了太多的坑须要去填补。洋洋洒洒一篇文章下来，中间的无数细节其实都须要无数技术栈上的攻关，直至到如今，仍然感受有不少地方须要完善改进，有许多方向能够追加。到了这个阶段所作的其实已经远不是传统测试范围内要作的事情，咱们须要考虑平台整体架构，须要考虑编码设计，须要本身去作交互设计，本身去作美工，咱们没有全职的前端（虽然我也有不少办法能够要到前端资源，但更倾向去全栈开发），须要和公司内部大大小小的平台作联调和对接，须要在各个技术团队落地应用。但这一切都颇有价值，团队内部应用的效果让整个研发小组（全职参与的其实没有几人）信心满满，人人充满动力团队迅速成长，因此....这会是一个招聘广告么呵呵，欢迎加入微医。