写点什么

在携程,我们如何实践 DevOps

2019 年 12 月 24 日

在携程,我们如何实践DevOps

如今很多大型互联网公司、创新型企业都在积极地进行 DevOps 实践和落地。为什么 DevOps 如此受青睐? 我们该如何实施 DevOps?DevOps 中 Dev 代表开发,Ops 代表运维,那么在这个崭新的流程体系中,QA 又该如何找到自己的位置?带着这些疑问和困惑,我们希望在本文中都能进行探索和解答。


一、业务和技术变革驱动流程的变革


以往在软件开发的世界里,以月甚至以年为周期进行发布是一种常态。但随着近些年由云、移动互联网、AI、社交技术以及区域链等技术推动的业务变革呈现爆炸式的发展。在这种大背景下,即使是大型的互联网公司也随时面临着业务上被淘汰的危险,持续的业务创新,快速的上线,卓越的用户体验以及快速的获得反馈才是企业制胜的法宝。


业务在高速变革,那么技术怎么样呢?技术的变革比之业务,有过之而无不及。应用架构从以往的服务集中到如今盛行的微服务,IT 架构从物理机、虚拟机到如今的容器化、云服务,开发技术栈无论是前端还是后端也都呈现百花齐放的姿态。


无论是业务变革还是技术变革,最终都会对企业的开发流程造成影响,并进而推动其进行变革。从早期的瀑布式开发,到敏捷开发,再到如今的 DevOps,其产生的背景无一不都有着业务和技术变革的影子。


为什么当前我们需要 DevOps,甚至很多大型的互联网公司也在进行 DevOps 转型,其中最关键是因为其核心思想能够满足当前业务和技术变革的需要,那就是“快速的交付价值,灵活的响应变化”。“快速的交付价值”意味着能先人一步占领市场,“灵活的响应变化”亦意味着减少变化带来的不利因素,使企业立于不败之地。



业务和技术变革推动流程变革


二、携程持续交付的现状和挑战


携程在很久以前就已经开始进行持续交付的建设,应用部署全部实现了容器化, 并实现了一套自动化程度较高的持续集成发布系统-Ctrip CD(后面简称 CD),CD 发布流程如下图所示:



携程发布流程图


开发人员在功能开发完成并提交代码后, 可以自己操作或通知测试进行环境部署。进行环境部署的人员可以在 CD 中创建发布版本,然后由 CD 自动进行代码编译,代码扫描,安全扫描,测试环境部署等操作。测试人员完成测试后进行测试结果的反馈。如果测试通过继续通过 CD 进行 UAT 环境的部署,进行验证测试。测试通过后,发布生产环境。


从上面流程图可以看出,整个发布过程自动化程度还是较高的,相关人员只要在 CD 中操作新建版本,关注发布状态就可以了。但我们仔细分析这个过程还是能发现不少问题:


1)持续集成的反馈链路过长。我们往往希望在开发人员每次提交代码时就进行代码编译,代码扫描,单元测试等过程,而不是在功能开发完成后进行。


2)人工介入依然过多。虽然在 CD 中可以完成大部分的编译,发布,部署等繁复且人工易出错的工作,但是否可以省略人工创建版本,测试环境手动测试,进而每次提交代码都触发一系列的操作,发布到 UAT 环境,甚至是生产环境(对于业务简单,单元测试和接口测试的应用)。


3)CD 发布系统解决了编译,部署,环境治理等大部分 OPS 相关的工作,但却没有考虑到如何把开发,测试以及发布后的监控等活动整合起来。


上面提到的这些问题,也是携程希望引入 Auto DevOps 的原因之一。DevOps 所提倡的“持续集成,持续测试,持续交付,持续部署”可以很好地解决这些问题,使整个研发效率提升。


三、DevOps 测试流程


携程 DevOps 是基于 GitLab CI/CD 为主干实现的,并针对携程内部的情况进行了二次开发,实现 auto devops 的能力。本文关注的重点是在 DevOps 过程中的测试实践,所以在此就不赘述携程 DevOps 的实现细节,仅列出携程 DevOps 的主干流程。



携程 DevOps 流程及测试流程图


DevOps 虽然从字面意义上看更着重于开发与运维的融合,但事实上却并非如此。DevOps 可以看成是开发、运维和 QA 三者的交集,所以 DevOps 实施成功的关键在于各个阶段都不能有短板。DevOps 通过自动化来实现“持续交付”的流程,那么自动化的手段中自然也包括测试的自动化。其倡导的“持续测试”也需要我们尽可能多的使用自动化手段来快速的发现和反馈问题,从而保障交付产品的质量。


我认为“持续测试”并不仅仅是频度上的持续,还包括开发过程上的持续。我们希望在开发过程的各个阶段都可以有测试的介入,“测试左移”和“测试右移”的思想也由此而来。那么在携程 DevOps 流程中,我们根据自身的情况分三个阶段来进行测试的介入。


第一阶段开发提交代码时,触发静态扫描(Sonar,Infer,代码风险扫描等),安全扫描,单元测试。如果这些测试不通过,将通知开发进行修复。


第二阶段开发提交代码后,经过编译并部署到测试环境时,触发接口测试、熔断测试、比对测试、性能测试等。


第三阶段测试环境测试通过后,发布到生产的镜像环境,在此环境进行流量回放测试,并进行发布前的验证确认工作,验证通过后可以进行生产发布。同时进行生产环境各项指标的监控工作。


在整个过程中, 我们也会收集 DevOps 指标数据,日志,性能,测试数据,进行测试分析,通过算法进行风险评估,从而为提高测试决策质量,效率提升提供依据。


俗话说“无规矩不成方圆”, 流程的制定只是搭了个架子。在这个架子下,我们还需要制定一系列流程标准来充实它,这也是相对比较困难的部分。因为制定的这些标准需要取得整个部门甚至整个公司的认可,并作为规范来严格的执行,这势必对现有的流程和规范造成很大的影响,推广难度还是比较大的。所以如有必要,甚至可以成立质量委员会来统一制定这些标准,并密切监控实施的过程,遇到问题和困难可以一起想办法解决。


那么通常的标准有哪些呢?归纳下来,这些标准包括:


  • 提测标准:静态扫描结果,单元测试通过率,覆盖率,接口测试结果…

  • 测试规范:探索测试,用例执行,接口测试分析,性能测试…

  • 发布规范:风险分析,发布检查项…

  • 监控规范:业务,性能,日志数据收集,预警的条件….


四、携程酒店 DevOps 测试平台– Moss


有了流程和标准,我们就夯实了实施 DevOps 的基础。接下来需要一个平台来实践这些流程和标准,可以选择 Gitlab CI/CD,也可以选择 Jenkins,亦或者 Gitlab 与 Jenkins 结合。我们选择了自建平台,理由如下:


1)无论是 Gitlab 还是 Jenkins 都需要进行较复杂的配置文件设置,对于开发和测试人员都有一定的学习成本,所以我们希望通过可视化配置的方式来简化配置过程,这样既能提高配置的效率,也能减少推广的难度。


2)携程酒店测试使用的工具和平台很多都是内部研发的,市面上的 DevOps 平台整合这些工具和平台并没有现成的方案可用。


3)我们希望 DevOps 测试过程并不仅仅是给测试看的,我们希望开发,测试,产品都可以从这个平台中看到自己需要的东西。


4)DevOps 最理想的状态是可以直接自动发布到生产。可目前现实的情况却很少有应用可以做到,那么我们希望提供尽可能多的评估和反馈数据来缩短发布确认的过程。



Moss 平台


4.1 DevOps 测试工具链


在实施 DevOps 过程中会涉及到很多的工具,我们把这些工具形象的称为工具链,而合理的整合工具链中的工具也是 DevOps 是否成功的关键因素之一。在测试各个阶段常用的测试手段通常包括静态代码扫描,单元测试,接口测试,UI 自动化测试,流量回放等等。而这些测试手段在业界都有比较成熟的开源框架,比如 SonarQube、Junit、Selenim、Appnium…. . 携程酒店测试根据自身情况,结合这些开源框架开发了一系列的平台和工具。



携程酒店 DevOps 测试工具链


静态扫描作为一种近乎零成本的测试手段,可以在早期发现代码中存在的代码缺陷,安全漏洞等问题。在静态扫描领域,SonarQube 已经深耕多年,在这方面已经近乎成为标配。携程通过对原有 SonarQube 代码规范库中的规范进行筛选和扩展,形成了自己代码规范库。我们还有基于开源框架开发的安全扫描工具 Cobra 和 Buffalo。在我们的 DevOps 流程中,开发人员在提交代码后就会触发 Sonar,Infer,Cobra,Buffalo 等一系列的静态扫描手段进行代码检测。


单元测试随着敏捷开发的盛行而引起了大家的重视,虽然目前在国内对单元测试的重视程度依然欠缺,但从众多大型的开源项目可以看出单元测试确实在软件的开发质量保障方面有着积极的作用。我们为了整合单元测试的编写,执行和结果而开发了 UTP 单元测试平台。该平台由 Junit 扩展库 UtpJunit,IDEA 插件 UtpGenerator 以及 Utp 站点组成。该平台实现了 BDD 驱动,代码分析,在线 WebIDE,单元测试执行,覆盖率统计,报告展示,持续集成等功能。


集成测试阶段主要进行接口测试,数据库测试,Job 测试等等。无论是 RPC,SOA 还是目前流行的微服务,都是在强调对外提供服务的能力。而这种能力主要通过提供对外接口来实现,这也决定了接口测试的重要性。我们为此构建了 CAS 平台,CAS 平台是一个同时支持有码和无码接口自动化测试的平台。



CAS 自动化测试平台


测试过程中一个比较难以解决的困难是测试数据问题。为了保障接口测试和 UI 自动化测试数据的可用性,我们开发了 MOCK 系统,用于测试人员配置和管理测试数据。


系统测试阶段是测试人员介入比较多的阶段,也是测试人员比较热衷做自动化测试的阶段。因此这个阶段的自动化测试框架也比较的多。常用的 Web 自动化框架有 Selenim,Jest,Jasmine…,常用的 APP 自动化测试框架有 Appnium,Airtest,Clabash,UIAutomator…. 而这些自动化测试框架是百花齐放,各有所长,要根据自身团队的实际情况慎重选择适合自己的框架。


在 Web 自动化测试方面,我们选择了 Selenium 框架作为基础进行二次开发,而在 APP 自动化测试方面,我们构建了自己内部的测试云平台- ATL(APP Test Lab),该平台支持设备管理,也同时支持 Appnium 和 Airtest 的用例管理,执行和报告查看。



ATL 自动化测试平台


线上监控作为”测试右移”的重要手段之一,正越来越引起很多公司的重视。通常在服务器,网络,框架,性能等方面,OPS 会有众多的监控和预警机制。但在业务,功能等一些特定指标上却无法兼顾到,那么我们就需要自己去监控和预警,这些监控大致可以分为数据库数据监控,埋点监控,接口监控,UI 监控等。



携程酒店测试监控平台


除了以上的工具和平台,我们还有一些经常使用的工具和平台,限于篇幅,不在这里一一介绍。而这么多的工具和平台,以往都是测试人员在各个平台切换使用,容易混乱,效率也低,工具之间无法产生化学反应。我们需要通过 DevOps 把这些工具整合起来,形成工具链,这也就是我们经常提到的 pipeline.



Moss 平台的 pipeline 整合了众多的工具和平台


4.2 DevOps 数据中心


DevOps 的精益思想需要数据支持来减少不必要的浪费,DevOps 是否成功得到实施需要数据来反馈各项指标数据,公司的领导需要知道当前团队代码问题,覆盖率情况,Bug 等数据… 等等这些都需要数据。


这些数据来源在哪里? 自然来自 DevOps 所整合的各个平台和工具。所以我们需要一个 DevOps 数据中心来收集和分析这些数据,并把数据以可视化的方式展示给相关的人员,让相关人员可以看到自己需要的数据。



DevOps 数据中心架构示意图


Moss 平台的 DevOps 数据中心通过收集器从各个工具链平台中拉取数据存放到 MongoDB 中。Neo4j 是一款 NOSQL 图形数据库,用于存放人与人,人与应用,应用与应用之前的关系和数据,为以后聚合团队数据,数据关联提供支持。


同时 DevOps 数据中心还提供了可视化数据编辑功能,可以让用户以可视化配置的方式来配置数据的可视化看板。而且秉承着一切数据都是可以被搜索的理念, 我们提供一个搜索引擎让用户搜索到自己想要的数据,并以可视化的形式展示出来。



应用看板,技术价值流看板


五、总结和未来展望


测试在历经了瀑布式开发,敏捷开发阶段后,其测试体系的基础并没有受到太多的冲击和改变,但在“来势汹汹”的 DevOps 浪潮中, 我认为测试的根基已经受到了一定的动摇,过去那种固有的测试思维已经难以适应当下测试的需要。作为测试人,如果不想被时代淘汰,就需要主动去适应这种转变,去积极挖掘测试在 DevOps 体系中的价值。


在实施 DevOps 的过程中,我们也遇到了很多的困难和挑战,同时也收获了很多的经验和教训。总结下来主要有这么几点:


  • 高度自动化,尽可能减少人为干预

  • 需要快速且准确的反馈问题

  • 要制定DevOps流程中可行的规范

  • 关注DevOps指标,优化流程和提高效率


目前, 我们实施的 DevOps 还处于初期阶段,很多方面尚未完全达到预期。在不久的将来我们还有很多的工作需要去做:


  • 进一步完善流程标准和挖掘数据来提高效率和软件质量

  • 采用机器学习来实现基于风险和变更的测试策略

  • 进一步加强质量可视化实现

  • 基于Moss的数据整合能力,实现监控一体化


开发 Chrome 插件 Moss Detector,进一步加强用户在 DevOps 中的交互和效率提升


作者介绍


王幸福,携程酒店研发部高级测试经理,负责无线自动化测试相关工作。在测试框架和平台研发、移动测试、DevOps 等领域有着丰富的经验。


本文转载自公众号携程技术(ID:ctriptech)。


原文链接


https://mp.weixin.qq.com/s?__biz=MjM5MDI3MjA5MQ==&mid=2697269235&idx=1&sn=db8dc40213db6df271b6d8328b7fd1cf&chksm=8376f0c7b40179d1cdeafc2d8b99a7690778a7b0f09cbc3a5c6657857069eb72cbc3b4faec9e&scene=27#wechat_redirect


2019 年 12 月 24 日 09:302923

评论

发布
暂无评论
发现更多内容

计算机网络基础(五)---网络层-IP地址的子网划分

书旅

laravel 计算机网络 网络协议 计算机基础

【DevCloud·敏捷智库】如何利用用户故事了解需求

华为云开发者社区

敏捷开发 需求管理 需求 故事 华为云

腾讯员工每天在岗不足 8 小时被辞?背后原因可能不止你看到的这些!

程序员生活志

腾讯 辞退

信创舆情一线--台积电宣布9月14日断供华为

统小信uos

华为 芯片 半导体

OOP面向对象编程(Object-Oriented Programming)概述

古月木易

面向对象 oop

编程核心能力之复用

顿晓

编程 复用 编程日课 技术思维

高价值干货:这可能是你见过最全的网络爬虫总结

华为云开发者社区

Python Web 爬虫 python 爬虫 内存数据库

分布式系统信息一致性问题与方案分析

superman

分布式 极客大学架构师训练营

调薪

池建强

团队管理 薪酬

分析师的进阶与升华:努力把自己做“没”

松子(李博源)

方法论 数据模型 数据分析师 指标体系 商业模型

字节跳动的ToB生意经

ToB行业头条

【写作群星榜】7.11~7.17 写作平台优秀作者 & 文章排名

InfoQ写作平台官方

写作平台 排行榜

全球区块链专利排行榜中国52家企业上榜

CECBC区块链专委会

小白教程——基于阿里云快速搭建自己的网站

诸葛小猿

阿里云 视频 网站搭建 小白

推荐一些学习MySQL的资源

Simon

MySQL

图解:最短路径之如何理解“松弛”or“放松”?

淡蓝色

Java 数据结构 算法

细数2020上半年PC端十大“黑恶势力”,一起康康是谁在“兴风作浪”

360安全卫士

OOP面向对象编程(Object-Oriented Programming)概述

奈学教育

面向对象编程

阿里巴巴取消周报?别高兴太早,也不见得是一件好事

非著名程序员

阿里巴巴 程序员 程序员成长 职场成长 职场误区

ARTS Week7

丽子

ARTS 打卡计划

YAPI接口管理平台使用基础入门(一)

Man

DevOps 最佳实践 YAPI API接口管理

2020技能排名:Python增速爆炸,SQL和Java老当益壮,AWS大吃一惊

程序猿黑哥

Java Python sql

Rust多线程之数据共享

编号94530

rust 多线程 数据共享 什么是多线程

为什么编译原理被称为龙书?

cxuan

编译原理 编译优化

犯罪黑客线上拉人入伙,流窜多地网吧植马,仅为盗取游戏账号

360安全卫士

我成功转行做了java程序猿!

诸葛小猿

Java 转行程序员 转行

上班摸鱼,可以玩一整天,哈哈哈!!!

诸葛小猿

上班 摸鱼

LeetCode题解:141. 环形链表,JavaScript,快慢指针,详细注释

Lee Chen

LeetCode 前端进阶训练营

Discuz插件设计

心平气和

php Diszuz 插件设计 插件系统

从IT建设模式变化看客户中心发展

环信

Week7 作业

Shawn

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

在携程,我们如何实践DevOps-InfoQ