在携程，我们如何实践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 的过程中，我们也遇到了很多的困难和挑战，同时也收获了很多的经验和教训。总结下来主要有这么几点：