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

转载自  https://testerhome.com/topics/12961  侵删

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到研发协作平台这个过程中，发现了太多的坑需要去填补。洋洋洒洒一篇文章下来，中间的无数细节其实都需要无数技术栈上的攻关，直至到现在，仍然感觉有很多地方需要完善改进，有许多方向可以追加。

到了这个阶段所做的其实已经远不是传统测试范围内要做的事情，我们需要考虑平台总体架构，需要考虑编码设计，需要自己去做交互设计，自己去做美工，我们没有全职的前端（虽然我也有很多办法可以要到前端资源，但更倾向去全栈开发），需要和公司内部大大小小的平台做联调和对接，需要在各个技术团队落地应用。但这一切都很有价值，团队内部应用的效果让整个研发小组（全职参与的其实没有几人）信心满满，人人充满动力团队迅速成长，所以....这会是一个招聘广告么呵呵，欢迎加入微医。